Java Files.find组合文件类型与大小条件的遍历方法

目录巡检常常不是“找到所有文件”这么简单：要排除目录，只看 .log，限制文件大小，还要避开过旧或过新的文件。Java NIO.2 的 Files.find 适合把这些条件放进一个 BiPredicate，由遍历器提供路径和基础属性，最终返回可继续处理的 Stream。

官方文档：https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html

一、先把 Files.find 的职责拆开

Files.find(start, maxDepth, matcher) 可以理解成“从某个 Path 开始，在指定深度内遍历，并只保留谓词返回 true 的路径”。start 决定目录根，maxDepth 决定搜索边界，matcher 接收当前路径和 BasicFileAttributes。这里的属性对象已经包含类型、大小和修改时间等信息，不必在谓词里再次读取同一文件的属性。

在规模较大的目录中，先把筛选边界说清楚很重要。类型条件解决“是不是普通文件”，扩展名解决“是不是目标格式”，大小和时间条件则回答“是否值得进入后续处理”。这些条件属于同一个筛选器，但各自的职责不要混在一起。

二、组合文件类型、扩展名、大小和修改时间

下面的例子筛选深度不超过 3 的普通日志文件：文件名以 .log 结尾，大小至少 1 MiB，且修改时间早于指定截止时刻。示例把阈值命名出来，后续调整规则时不需要在 lambda 中寻找魔法数字。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.attribute.BasicFileAttributes;
import java.time.Instant;
import java.util.stream.Stream;

public class LogFileFinder {
    public static Stream findOldLargeLogs(Path root, Instant cutoff) throws IOException {
        long minimumBytes = 1024L * 1024L; // 只保留至少 1 MiB 的文件
        int maxDepth = 3; // 限制目录遍历层数，避免无边界扫描

        return Files.find(root, maxDepth, (path, attrs) ->
                attrs.isRegularFile() // 先排除目录、符号链接目标之外的非普通文件
                        && path.getFileName().toString().endsWith(".log") // 只保留日志后缀
                        && attrs.size() >= minimumBytes // 使用已取得的属性判断大小
                        && attrs.lastModifiedTime().toInstant().isBefore(cutoff)); // 筛出截止时间前修改的文件
    }

    public static void main(String[] args) throws IOException {
        Path root = Path.of("/var/app/logs"); // 示例目录，实际项目中应从配置读取
        Instant cutoff = Instant.now().minusSeconds(7 * 24 * 60 * 60); // 以七天前为时间边界

        try (Stream files = findOldLargeLogs(root, cutoff)) { // 及时关闭 Files.find 返回的流
            files.forEach(System.out::println); // 这里只展示匹配路径，不代表已删除或归档
        }
    }
}

这个组合的关键是“先类型、后属性、最后业务条件”。BasicFileAttributes 的 size() 与 lastModifiedTime() 适合做筛选输入；如果任务还需要读取文件内容，应把读取动作放到流消费阶段，并单独处理读取异常。

三、深度、符号链接和资源关闭要单独判断

maxDepth 控制的是目录树深度，不是返回结果条数。设置为 1 通常只检查根目录及其直接子项；设置得更大，遍历范围会随目录结构扩大。对于定时巡检，宁可先给出明确深度，再根据业务目录布局逐步扩大。

默认情况下，示例只通过 attrs.isRegularFile() 接受普通文件。不要把“能读到一个 Path”误认为“就是目标文件”。如果业务必须跟随符号链接，应显式评估 FileVisitOption.FOLLOW_LINKS 的影响，包括循环链接、权限错误和扫描范围扩大等边界。

资源管理是 Files.find 最容易被忽略的部分。返回的流不仅是一组惰性路径数据，也可能关联遍历中的目录句柄。使用 try-with-resources 包住整个消费过程；不要先把流返回到更外层，却让创建它的方法提前结束。

四、用检查清单确认筛选结果

当筛选条件继续增加时，优先拆成有名字的 Predicate 或辅助方法，而不是让一条 lambda 横向增长。这样更容易针对“后缀正确但大小不符”“时间合适但类型不符”分别解释结果，也便于未来切换到 Files.walk 或 walkFileTree。

常见问题

Files.find 和 Files.walk 该怎么选？

只需要按路径和基础属性筛选时，Files.find 更直接；需要先拿到路径再组合复杂流操作时，可以考虑 Files.walk。两者都应关注遍历深度和流的关闭。

为什么文件大小条件看起来不准确？

BasicFileAttributes.size() 返回的是字节数，阈值要按字节计算；另外，文件可能在扫描后被其他进程继续写入，所以筛选结果不等于后续读取时的最终大小。

是否应该默认跟随符号链接？

通常不应默认开启。只有当业务目录明确依赖链接目标时才评估 FOLLOW_LINKS，并补上循环、权限和重复扫描的处理边界。