Java Files.find 和 Files.walk 在过滤条件上怎么选择

Java NIO 里，Files.find 和 Files.walk 都能搜索目录树，但选法并不是“哪个更快”。需要直接使用文件属性（大小、类型、时间）来决定是否保留节点时，优先用 Files.find；需要先拿到路径，再组合 filter、map、排序或其他 Stream 操作时，Files.walk 更顺手。

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

先看过滤条件：是路径判断，还是属性判断

如果条件只是扩展名、目录名或路径前缀，例如“找 logs 目录下的 .log 文件”，路径本身已经够用。如果还要判断“普通文件且大于 10 MB”，就需要读取 BasicFileAttributes。这一步决定了过滤器应该放在 API 参数里，还是放在返回的 Stream 上。

Files.find：属性条件直接写进 BiPredicate

find 的签名包含 BiPredicate。它仍然按文件树方式遍历，但只有匹配器返回 true 的路径进入结果流。下面的例子寻找两层以内、扩展名为 .log 且大小至少 10 MB 的普通文件：

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

public class FindLargeLogs {
    public static void main(String[] args) throws IOException {
        Path root = Path.of("/var/app");

        // find 同时提供路径和属性，避免先过滤再重复读取文件属性。
        try (Stream files = Files.find(root, 2,
                (path, attrs) -> attrs.isRegularFile()
                        && path.getFileName().toString().endsWith(".log")
                        && attrs.size() >= 10 * 1024 * 1024)) {
            // 终端操作消费惰性流；try-with-resources 会关闭内部目录。
            files.forEach(System.out::println);
        }
    }
}

这里的 2 是最大目录深度，0 只检查起点本身。属性读取和过滤放在同一个匹配器里，适合条件明确、结果直接用于终端操作的搜索。官方 API 也提示，与 walk(...).filter(...) 相比，这种写法可能避免重复获取 BasicFileAttributes。

Files.walk：先拿路径，再用 filter 组合条件

walk 返回完整的 Stream，默认深度优先访问目录，且默认不跟随符号链接。它的优点是路径流可以继续接上多个操作：先过滤普通文件，再按路径名筛选，最后转换成相对路径。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.stream.Stream;

public class WalkByPath {
    public static void main(String[] args) throws IOException {
        Path root = Path.of("/var/app");

        // walk 负责产生路径；路径条件适合继续组合 Stream 操作。
        try (Stream paths = Files.walk(root, 3)) {
            paths.filter(Files::isRegularFile) // 只保留普通文件，排除目录。
                    .filter(path -> path.getFileName().toString().endsWith(".log"))
                    .map(root::relativize) // 输出相对路径，便于写入索引或日志。
                    .forEach(System.out::println);
        }
    }
}

如果过滤逻辑本身还要读取大小或修改时间，继续在 walk 后调用 Files.size、Files.getLastModifiedTime 可能产生额外属性访问。此时应重新评估是否改用 find，而不是盲目追求一条更长的 Stream。

关闭资源与异常边界：两种写法都不能省略

这两个方法返回的是惰性流，流的背后可能保留一个或多个打开的目录。只写 Files.walk(root).filter(...).toList() 而不关闭流，在批处理或长时间运行的服务里容易积累文件描述符。推荐始终写成 try-with-resources。

方法创建起点时可能直接抛出 IOException；遍历开始后，如果访问目录失败，异常可能以 UncheckedIOException 的形式从流操作冒出来。生产代码可以在外层统一记录当前根目录和深度，不要只记录“扫描失败”四个字。

按选择清单落地到实际项目

1. 条件需要 BasicFileAttributes，例如大小或普通文件类型：先选 Files.find。
2. 条件主要是路径，且后续需要 map、排序或多次组合：选 Files.walk。
3. 目录很大时先设合理的 maxDepth，不要默认无限层级。
4. 若要跟随符号链接，明确传入 FOLLOW_LINKS，同时考虑循环目录导致的 FileSystemLoopException。

常见问题

Files.find 会比 Files.walk 快吗？

不能脱离文件系统和条件直接下结论。它在属性过滤场景可能避免重复读取属性，但遍历规模、磁盘状态和后续终端操作仍会影响结果。

只按文件名过滤，也能用 Files.find 吗？

可以。只是如果没有属性条件，walk 的路径流写法通常更直观；选择应看后续处理链，而不是只看方法名。

maxDepth 设成 Integer.MAX_VALUE 安全吗？

它表示访问所有层级，不代表内存或耗时无限可控。面对用户可配置目录时，建议设置业务上限并记录遍历范围。

一句话记忆：属性条件放进 find，路径流组合交给 walk；无论选哪一个，都把流放进 try-with-resources。