Java PathMatcher glob 怎么筛配置文件：glob 规则、相对路径与空匹配排查

服务启动时只想读取 conf/ 下的 application-*.yml，结果配置一份都没有命中，甚至把子目录里的测试文件也误扫了出来。这个问题通常不是 glob 写错，而是匹配器接收的 Path 层级和通配符的边界没有对齐。

PathMatcher 为什么经常“看起来写对却匹配不到”

FileSystem.getPathMatcher 返回的是当前文件系统的路径匹配器。它接收的不是文件内容，也不是脱离目录的文件名，而是一个 Path 对象。因此下面两种输入不是一回事：

Path.of("application-prod.yml")
Path.of("conf/application-prod.yml")

如果匹配器写成 glob:application-*.yml，第一种输入符合预期，第二种输入前面多了 conf/，自然不会命中。工程里更稳的做法是把遍历根目录固定为 conf，再把每个候选文件转换成相对路径交给匹配器。

这也是这个小模式的核心：遍历负责找到候选项，PathMatcher 负责判断相对路径是否符合规则。不要让一个 glob 同时承担目录定位、文件遍历和业务过滤三件事。

glob 规则先看路径层级，再看通配符

项目规范如果只允许 conf/ 根目录和一层环境目录，优先使用更窄的规则。规则越宽，后续误读示例配置、备份文件和测试夹具的概率越高。

一个可验收的配置扫描器

下面的程序将根目录外的路径信息隔离掉，限制遍历深度，并只保留普通文件。PathMatcher 只收到相对路径，所以规则的含义稳定，换到另一台机器也不会因为绝对路径不同而失效。

import java.io.IOException;
import java.nio.file.FileSystem;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.PathMatcher;
import java.util.Comparator;
import java.util.List;
import java.util.stream.Stream;

public class ConfigScan {
    static List find(Path root, String pattern) throws IOException {
        try (FileSystem fs = root.getFileSystem();
             Stream paths = Files.walk(root, 3)) {
            PathMatcher matcher = fs.getPathMatcher("glob:" + pattern);
            return paths.filter(Files::isRegularFile)
                    .map(root::relativize)
                    .filter(matcher::matches)
                    .sorted(Comparator.comparing(Path::toString))
                    .toList();
        }
    }

    public static void main(String[] args) throws IOException {
        Path root = Path.of("conf").toAbsolutePath().normalize();
        List matches = find(root, "**/application-*.yml");
        matches.forEach(System.out::println);
    }
}

这里的 FileSystem 来自根路径本身，能避免手工拼接平台分隔符。Files.walk(root, 3) 返回惰性流，必须放进 try-with-resources；否则目录句柄可能直到垃圾回收才释放。排序不是匹配必须条件，但它让启动日志和测试断言稳定。

空匹配从四个检查点开始排查

1. 根目录：打印 root 和 Files.exists(root)，确认程序运行目录没有变化。
2. 相对路径：临时打印 root.relativize(path)，确认匹配器看到的是 env/application-prod.yml 还是完整绝对路径。
3. 规则：先用 glob:*.yml 验证同层文件，再逐步加入子目录和多后缀，不要一次写出最宽规则。
4. 文件名：Linux 文件系统通常区分大小写，Application-prod.yml 不等于 application-prod.yml。

如果只需要根目录文件，不要用 ** 再靠业务代码排除子目录。把扫描深度和 glob 同时收窄，问题更容易定位，误匹配也更少。

PathMatcher 适合做哪一层判断

它适合做“路径形状是否符合规则”的判断，例如配置文件、模板文件和资源清单。它不负责判断文件是否可读、内容是否是合法 YAML，也不负责决定哪个环境配置拥有最高优先级。生产代码可以把流程拆成三步：先限制根目录和深度，再匹配相对路径，最后读取并校验内容。

当规则开始出现大量业务条件，例如文件名、修改时间、文件大小和环境变量必须同时满足时，建议保留 PathMatcher 做第一道筛选，把其余条件写成可测试的谓词。这样规则变更不会悄悄扩大文件访问范围。

常见问题

PathMatcher 的 glob 和正则表达式能混用吗？

不能直接混用。创建匹配器时要明确写 glob: 或 regex:，两者的转义和通配符规则不同。只需要文件名通配时，glob 通常更容易读。

为什么 glob:*.yml 匹配不到子目录文件？

因为传入的相对 Path 含有目录层级。可以改成明确的一层规则，或使用 **/ 表示多层路径，同时用 Files.walk 的最大深度控制扫描范围。

Files.walk 的流需要手动关闭吗？

需要。把它放在 try-with-resources 中，遍历完成、发生异常或提前结束时都能及时释放底层资源。

Windows 和 Linux 的 glob 结果会不一样吗？

可能会。路径分隔符、大小写敏感性和默认文件系统规则都可能影响结果。使用 root.relativize 生成 Path，不要手工拼接字符串，并在目标系统上做一条真实路径验收。

配置扫描的关键不是把 glob 写得越来越复杂，而是先固定根目录、相对化路径，再用最窄规则验证。只要这三个边界清楚，空结果和误命中的定位成本都会明显下降。