Linux find按文件大小和修改时间清理缓存的安全流程

缓存目录清理最怕的不是命令太长，而是匹配范围写得太宽。比较稳妥的做法是把目录、文件类型、大小和年龄写成同一组条件：先用 -print 只打印候选清单，确认路径和数量后，再把最后一个动作替换为 -delete。这样既能利用 Linux find 的条件组合，也不会把一次排查直接变成不可逆删除。

清理缓存时，先固定绝对路径并用 -xdev -mindepth 1 -type f 收窄范围，再用同一条表达式复核候选，最后才执行 -delete。不要直接把宽泛的 rm 或管道删除命令放进定时任务。

先把缓存清理边界写清楚

假设应用缓存固定在 /srv/app/cache，目标是找出大于 100 MiB、修改时间超过 7 个完整 24 小时周期的普通文件。示例里的路径只是说明，生产环境应替换成已经确认的缓存根目录，并避免使用 /、/var 这类过宽起点。

root=/srv/app/cache
# 固定搜索根，避免变量为空时意外从当前目录开始扫描
find "$root" -xdev -mindepth 1 -type f -size +100M -mtime +7 -print

这里的 -xdev 不跨越其他文件系统，适合缓存目录里挂载了独立磁盘或容器卷的场景；-mindepth 1 排除搜索起点本身；-type f 则把目录、设备文件和符号链接排除在外。-print 阶段不改变任何文件，适合先保存输出并人工确认。

理解 -size 与 -mtime，别被数字骗了

-size +100M 使用 GNU find 的大小单位，M 表示 MiB；大小比较存在单位取整，所以它不等价于简单的字节比较。若任务要求严格的字节阈值，应改用 -printf 输出实际大小后再设计更精细的处理，而不是只改一个后缀。

-mtime n 按 24 小时周期计算修改时间，+7 表示严格超过 7 个周期。凌晨运行和白天手工运行可能得到不同边界结果，因此定时任务不要把“7天”理解成自然日零点。需要按分钟控制时，可以考虑 -mmin，并在候选清单里观察实际时间。

候选确认后再执行删除

确认打印出的路径都属于可重建缓存、没有命中正在写入的临时文件后，复用完全相同的表达式，只把动作改成 -delete：

root=/srv/app/cache
# 先确认 root 非空且是预期目录，再执行不可逆动作
test -n "$root" && test -d "$root" || exit 1
# 保持筛选条件不变，只删除符合条件的普通文件
find "$root" -xdev -mindepth 1 -type f -size +100M -mtime +7 -delete

GNU Findutils 文档把 -delete 作为直接删除动作，它成功删除时返回真，失败时会输出错误并让 find 最终以非零状态退出。它还会自动启用 -depth，所以原本依靠 -prune 跳过子目录的写法不能原样拼到这条命令后面。若需要排除目录，优先把允许清理的目录分别列为搜索起点，或先用打印阶段生成清单再做人工复核。

放进定时任务前的检查清单

• 把缓存根目录写成绝对路径，并在脚本开头检查变量非空、目录存在。
• 保留一次 -print 输出或数量统计，先观察一轮再启用删除。
• 使用专用服务账号和最小目录权限，不要为了让 cron 成功而直接放大到 root。
• 把标准输出和错误输出写入轮转日志，关注删除失败、权限不足和挂载变化。
• 缓存必须具备重建路径；数据库文件、上传目录和持久化队列不应套用同一清理表达式。

常见问题

为什么打印出来的文件比预想的少？

因为条件默认是 AND 关系，文件必须同时满足普通文件、大小阈值和修改时间阈值；另外 -mtime 按完整 24 小时周期取整，边界文件可能暂时不匹配。

可以把 -delete 换成 rm 吗？

不建议把未审查的路径列表通过命令替换交给 rm。文件名含空格、换行或数量过多时都容易出错；如果确实需要外部命令，应采用能正确处理 NUL 分隔路径的方案，并保留同样的范围约束。

如何排除缓存目录里的某个子目录？

-delete 自动启用 -depth，会让依赖 -prune 的排除写法失效。更稳妥的做法是把允许清理的子目录单独列为搜索起点，先逐个打印候选，再逐个启用删除。

这套流程的核心不是记住一条危险命令，而是让“搜索根、匹配条件、审查输出、删除动作”保持可对照。缓存规则一旦变更，先改打印阶段并观察结果，再同步到删除阶段和定时任务。