meta 目录里 4000 个空文件，我用 find 找出它们又不敢删

上周清一个 meta 目录时顺手跑了 du -sh，结果是 3.1G，但同目录下 du -sh –apparent-size 只有 480M。差得太多，说明大部分体积是块占用而不是真实内容。我怀疑里面塞了大量空文件和小文件，于是先只做统计，不做任何删除。

先数文件：

find . -type f | wc -l          # 4127
find . -type f -empty | wc -l   # 3962

4127 个文件里 3962 个是空的，占 96%。再看这些空文件分布在哪：

find . -type f -empty -printf '%h\n' | sort | uniq -c | sort -rn | head -20

结果集中在两个子目录，命名像 cache/ 和 tmp/，但路径里有版本号片段，比如 cache/2024.11/。这说明不是随机残留，是某个流程按版本目录建了文件却没写内容。

然后确认它们是不是真的一直为空，而不是我读的时候刚好在写：

find . -type f -empty -mtime +2 -printf '%TY-%Tm-%Td %p\n' | head -5

加上 -mtime +2 只留两天前就没动过的，数量从 3962 降到 3901。剩下 61 个是近期文件，我不碰。

为什么先数不删：空文件本身不占内容空间，但每个 inode 和目录项都要成本，备份、rsync、打包时也会被逐个遍历。我这边打包 tar 时 4000 个空文件让清单多出近 1MB，解包端还会逐个创建。另外这个目录被一个校验脚本按文件名遍历，空文件会让脚本多跑一轮读取，日志里有对应的 open 记录。

代价是：删之前我得确认校验脚本不依赖“文件存在”这个事实。我去翻了脚本，它是先 os.walk 再读内容，空文件读到空串就跳过，不报错。但另一个下游工具会用文件存在与否判断版本是否初始化过，这个我没法从脚本里看出来，所以最后只把 cache/ 下 3901 个两天前的空文件列成清单交给维护的人，没有自己动手。

边界也记一下：-empty 对目录也成立，我第一次漏了 -type f，把空目录也算进去，数量虚高。另外如果文件系统开了压缩或去重，du 的差值可能没这么大，别拿我这组数字当基准。

现在的问题是：你们那边判断一个空文件是“流程占位”还是“残留”，是看修改时间、看路径约定，还是有别的信号？我目前只有 mtime 这一条线，感觉不够稳。