Java中正则删文件需分两步：先用正则匹配文件名（非全路径），再在限定基路径、深度限制、符号链接校验及预览确认后谨慎执行，高保障场景应结合SecureDirectoryStream绑定操作边界。
Java 本身不支持用正则表达式直接驱动文件系统删除操作（如 rm -r 那样），所以“用正则匹配后删文件”必须分两步：先安全筛选，再谨慎执行。关键不是正则多强大，而是如何把匹配逻辑嵌入到受控、可审计、有边界、带防护的清理流程中——尤其面对可能误伤 /etc/、/usr/lib 或项目 config/ 等核心路径时。
限定扫描范围，从源头规避越界风险
绝不能让正则在根目录或用户主目录全盘扫描。必须显式指定清理起点，并禁止向上穿越：
- 只允许传入明确的、相对项目生命周期管理的路径，例如：
Paths.get("target/temp")、Paths.get("logs/archive")，而非Paths.get("/")或Paths.get(System.getProperty("user.home")) - 使用
Files.walk()时加深度限制（.maxDepth(3)）和路径前缀校验，例如检查每个Path是否以目标基路径开头：path.startsWith(baseDir) - 跳过符号链接（
!Files.isSymbolicLink(path)），防止正则意外匹配到挂载点或敏感重定向位置
正则仅匹配文件名，不参与路径解析
文件系统安全的核心是「路径可信」。正则应只作用于 path.getFileName().toString()，而不是完整路径字符串——否则 .*.jar 可能误中 /usr/share/java/spring-core.jar。
- 正确做法：
Pattern.compile("temp_\d{8}\.log").matcher(path.getFileName().toString()).matches() - 错误做法：
Pattern.compile(".*/temp_\d{8}\.log").matcher(path.toString()).find()（引入路径上下文，易绕过基目录约束） - 若需按目录层级过滤（如排除
config/下所有文件），用Files.isDirectory()+path.getParent().getFileName()显式判断，不依赖正则捕获路径段
执行前强制预览与白名单双重校验
任何正则匹配结果都不可直接删除，必须经过人工可读的确认环节或策略白名单兜底：
立即学习“Java免费学习笔记（深入）”；
- 将匹配到的
Path列表先写入日志或控制台，格式为：[DRY-RUN] Would delete: logs/temp_20260720.log，并暂停等待确认（开发/测试环境）或写入审核队列（生产环境） - 内置硬编码白名单：对含
"application.properties"、"cert.pem"、"schema.sql"等关键词的文件名，无论正则是否匹配，一律跳过删除 - 结合
Files.isReadable()和Files.getLastModifiedTime()做二次过滤，例如跳过 7 天内修改过的文件，避免刚生成的关键临时资源被清掉
用 SecureDirectoryStream 绑定操作边界（高保障场景）
当清理逻辑运行在权限较高、且目录内容可信度低的环境（如容器内配置卷、插件沙箱），推荐用 SecureDirectoryStream 替代普通 Files.walk()：
- 先用
Files.newDirectoryStream(baseDir)打开目标目录句柄，后续所有delete()、readAttributes()都基于该句柄执行，彻底杜绝 TOCTOU 竞态和符号链接逃逸 - 此时正则只用于筛选
SecureDirectoryStream返回的Path名称（即纯文件名），所有路径操作天然受限于打开时的目录实例，物理上无法跳出 - 适用于清理
/run/myapp/、/var/cache/myapp/tmp/这类短生命周期目录，不适用于跨挂载点或动态路径场景
