Java Files.find 怎样按属性过滤文件

我第一次把文件扫描从“先遍历，再读取属性”改成 Files.find 时，真正省下来的不是一行代码，而是少了一次重复的属性读取。这个 API 的匹配器会同时收到路径和 BasicFileAttributes，所以普通文件、大小、修改时间等条件可以直接写在同一个判断里。

官方地址：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/nio/file/Files.html

按属性过滤文件时，用 Files.find(start, maxDepth, matcher)，在 matcher 中读取 BasicFileAttributes；消费返回的 Stream 时必须使用 try-with-resources，因为遍历流可能持有打开的目录资源。

Files.find 的三个参数分别控制什么

start 是遍历起点，maxDepth 是最大层级，第三个参数是接收 Path 与 BasicFileAttributes 的 BiPredicate。深度从起始路径的 0 层算起，因此只查起点时可以用 0；查起点和下一层子项时可以用 1。

下面这个例子只返回普通文件，且要求文件不小于 1 MiB。示例把筛选条件放进 matcher，避免先把所有路径放入流后再额外读取属性。

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

Path root = Path.of("/data/inbox");

try (Stream files = Files.find(
        root,
        3,
        (path, attrs) -> {
            // 只保留普通文件，排除目录和其他文件类型。
            boolean regularFile = attrs.isRegularFile();
            // 属性来自遍历过程，直接按字节数判断文件大小。
            boolean largeEnough = attrs.size() >= 1024 * 1024;
            return regularFile && largeEnough;
        })) {
    // 这里消费结果流；离开 try 块时会关闭遍历资源。
    files.forEach(System.out::println);
} catch (IOException e) {
    // 起点无法访问或创建遍历时，按入口 I/O 错误处理。
    throw new IllegalStateException("无法扫描目录", e);
}

把文件属性过滤写进 matcher

匹配器不是只能判断文件名。BasicFileAttributes 已经提供了是否为普通文件、文件大小、修改时间等常用属性。多个条件建议拆成有名字的布尔变量，这样后面改动筛选边界时，不容易把“文件类型”和“业务条件”混在一起。

例如按最近七天修改过的普通文件过滤，可以直接使用 lastModifiedTime()。时间条件最好先在循环外计算截止时间，避免每个文件都重新生成一次。

import java.io.IOException;
import java.io.UncheckedIOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.time.Instant;
import java.time.temporal.ChronoUnit;
import java.util.stream.Stream;

Instant cutoff = Instant.now().minus(7, ChronoUnit.DAYS);

try (Stream recentFiles = Files.find(
        Path.of("/data/inbox"),
        3,
        (path, attrs) -> {
            // 先限制文件类型，再比较最后修改时间。
            return attrs.isRegularFile()
                    && attrs.lastModifiedTime().toInstant().isAfter(cutoff);
        })) {
    recentFiles.forEach(path -> {
        // 这里只处理已经通过属性条件的路径。
        System.out.println(path);
    });
} catch (IOException e) {
    // 创建遍历时的 I/O 异常仍然以受检异常形式出现。
    throw new IllegalStateException("扫描入口失败", e);
} catch (UncheckedIOException e) {
    // 惰性遍历过程中发生的 I/O 问题可能在消费流时才暴露。
    throw new IllegalStateException("扫描过程中读取目录失败", e.getCause());
}

为什么返回的 Stream 必须及时关闭

Files.find 返回的是惰性流，调用方法本身并不等于所有目录都已经访问完。Oracle API 明确说明，返回流可能包含一个或多个打开的目录，关闭流才会释放这些目录。把流交给调用方长期保存，或者只调用一次 find 却不消费、不关闭，都会让资源边界变得不清楚。

最稳妥的习惯是让创建流的代码紧挨着 try-with-resources。这样无论 forEach 正常结束，还是中途抛出异常，Java 都会执行流的关闭逻辑。

几个容易忽略的过滤边界

• 不要把 maxDepth 当成数量限制。它限制的是目录层级，不是结果条数；需要限制条数时，应在消费流时明确使用 limit，并仍然保留关闭流的结构。
• 区分入口异常和延迟异常。方法创建阶段可能抛出 IOException，真正遍历目录时的 I/O 问题可能包装成 UncheckedIOException，处理位置不要只写一处。
• 符号链接要有明确策略。默认按普通文件树遍历；只有业务确实需要跟随符号链接时才传入对应选项，并提前考虑循环、权限和重复路径。
• 属性读取也有文件系统边界。属性是遍历时读取的快照式信息，文件可能在匹配后被其他进程移动或删除；如果后续要打开文件，仍然需要单独处理打开失败。

相关问题

Files.find 和 Files.walk 后再 filter 有什么区别？

Files.find 直接把属性匹配器放在遍历接口上，适合属性条件明确的场景；Files.walk 更适合先得到路径流、再组合多个流操作。无论选哪一个，只要返回流可能持有目录资源，就应使用 try-with-resources。

只想查当前目录，maxDepth 应该写多少？

起始路径本身是 0 层，所以只检查起始路径使用 0；要包含它的直接子项使用 1。目录结构复杂时，先画清楚允许的层级，再决定这个参数，通常比事后过滤路径更直观。