Java PathMatcher 怎样按 glob 规则筛选文件

我第一次把“只处理 Java 文件”塞进目录遍历时，直觉是把 *.java 当作正则表达式传给筛选器。真正换成 Java NIO 的 PathMatcher 后，思路会清楚很多：FileSystem.getPathMatcher("glob:*.java") 负责创建匹配器，PathMatcher.matches(Path) 负责判断一个路径是否命中，目录流只负责提供候选路径。

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

要按 glob 规则筛选文件，先用 FileSystems.getDefault().getPathMatcher("glob:模式") 创建匹配器，再把目录遍历得到的 Path 交给 matches。最容易出错的地方不是 API 调用，而是模式到底匹配文件名，还是匹配包含目录层级的完整路径。

先把 glob、PathMatcher 和 Path 分开

PathMatcher 是一个很小的职责接口：它只回答“这个 Path 是否匹配当前模式”。模式由 FileSystem.getPathMatcher 解析，格式是 syntax:pattern；Java 默认文件系统支持 glob 和 regex 两种语法。这里的重点是，匹配器比较的是 Path 的字符串表示，不会替你递归目录，也不会自动把相对路径改成文件名。

因此可以先记住三层边界：

• glob 模式描述要匹配的路径形状，例如 *.java。
• PathMatcher保存语法和模式，提供 matches。
• Path是实际被比较的路径对象，可能包含目录层级。

常用 glob 模式怎样写

如果你的遍历对象只是某个目录下的直接子项，可以从文件名模式开始。* 通常表示一段字符，? 表示一个字符，花括号可以表达多个后缀。例如 *.java 匹配 Java 文件，*.{java,class} 允许两种后缀。模式前面的 glob: 不能省略，因为它告诉文件系统使用哪种语法。

import java.nio.file.FileSystems;
import java.nio.file.Path;
import java.nio.file.PathMatcher;

public class GlobMatcherExample {
    public static void main(String[] args) {
        // glob: 前缀声明语法，后面的模式只承担匹配规则。
        PathMatcher matcher = FileSystems.getDefault()
                .getPathMatcher("glob:*.{java,class}");

        Path candidate = Path.of("Report.java");
        // matches 只判断当前 Path，不负责遍历目录或读取文件内容。
        boolean matched = matcher.matches(candidate);
        System.out.println(matched);
    }
}

这段写法适合“候选 Path 已经是文件名”的场景。不要把它误解成“所有目录中的 Java 文件都能被一次找到”；查找候选仍然需要 Files.list、Files.walk 或其他目录 API。

把匹配器放进目录遍历

实际项目里，我更常用“目录流提供候选、匹配器负责筛选”的组合。下面的示例只处理目标目录的直接子项，Files.list 返回的流需要在 try-with-resources 中关闭。代码中的 getFileName() 很关键：它把完整路径裁成文件名，再交给 *.java 这种文件名模式。

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

public class ListJavaFiles {
    public static Stream listJavaFiles(Path directory) throws IOException {
        // 只匹配文件名，避免把目录层级也混入 *.java 的语义。
        PathMatcher matcher = FileSystems.getDefault()
                .getPathMatcher("glob:*.java");

        // Files.list 返回惰性目录流，交给调用方前先保留资源关闭责任。
        Stream entries = Files.list(directory);
        return entries
                .filter(Files::isRegularFile)
                .filter(path -> matcher.matches(path.getFileName()));
    }
}

如果调用方把返回的流继续交给其他方法，应该由调用方关闭它；也可以把遍历和收集写在同一个 try 块里。这里没有把整个文件读入内存，筛选动作只依赖路径对象和文件类型判断。

路径层级是 glob 最容易误判的地方

当传给 matches 的是 src/main/java/App.java 这样的相对路径时，glob:*.java 未必表达“任意深度的 Java 文件”，因为模式中的路径分隔符和候选 Path 的层级都参与了比较。想按文件名匹配，就先使用 path.getFileName()；想约束目录层级，就把层级写进模式，例如 glob:src/*/java/*.java，并结合当前文件系统的路径表示来组织候选。

递归遍历时，另一种清晰做法是让 Files.walk 负责深度，匹配器只负责文件名：

try (Stream paths = Files.walk(root)) {
    // 遍历深度交给 walk，glob 只约束每个文件的名字。
    paths.filter(Files::isRegularFile)
            .filter(path -> matcher.matches(path.getFileName()))
            .forEach(path -> System.out.println(path));
}

如果确实要匹配完整相对路径，先统一相对路径的根和分隔符，再构造模式。不要一边传绝对路径，一边使用只针对文件名设计的模式，否则“规则没有报错但结果为空”是很自然的结果。

glob、regex 和大小写边界怎么取舍

glob 适合文件名后缀、简单通配和少量候选分支；它比正则更容易让维护者一眼看懂。需要捕获组、字符范围或更复杂约束时，才考虑 regex:。不过两者都不会替你解决大小写策略：文件系统是否区分大小写、输入路径是否已经规范化，都会影响最终结果。

我会怎样收敛这段文件筛选代码

我现在会把模式作为方法参数，把“遍历候选”和“判断命中”留在同一层，并在方法名里写清楚匹配的是文件名还是相对路径。这样换成 *.xml 时不需要复制一套遍历逻辑，也不会让调用方误以为 glob 是一个文件搜索引擎。

最后可以用三句话检查设计是否清楚：

• 谁提供候选路径：Files.list 还是 Files.walk？
• PathMatcher 比较的是文件名还是完整路径？
• 模式是否依赖当前文件系统的分隔符与大小写规则？

相关问题

PathMatcher 的 glob 能直接递归目录吗？

不能。PathMatcher 只负责判断一个 Path 是否匹配，递归需要由 Files.walk 等遍历 API 提供。

*.java 为什么匹配不到带目录的 Path？

因为候选 Path 可能包含目录层级。若目标只是文件名，先调用 getFileName()；若要匹配层级，则把目录结构写进 glob。

什么时候应该改用 regex？

当规则需要复杂字符范围、分组或更细的文本约束时再用 regex；普通后缀、单字符和有限分支优先保持 glob 的可读性。