批处理按日期切分日志，我加了行数预检才敢自动删旧包

先别急着吹自动化，切分脚本翻过车

之前写了个批处理，每天凌晨把 logs/ 下超过 7 天的 .tar.gz 按日期切分归档，顺手删掉源包。逻辑看着没问题，结果有一次一个日志包被下游程序写坏了，tar -tzf 直接报错，for /f 把错误信息当文件名，差点把当天正在写的日志目录给删了。

从那以后我的原则很简单：任何自动删包脚本，前面必须加一道行数预检。

我现在跑的流程（Win 11 23H2 + 7-Zip 24.08 命令行 + 批处理）

1. 列包先验完整性：7z t 每个 .tar.gz，退出码非 0 的直接挪到 quarantine/，不参与后续切分。
2. 按日期分组前先数行：7z l -slt 输出文件列表，用 findstr /c:"Path = " 抓行，再按日期前缀分组。行数跟预期文件数差超过 10% 就告警，不删任何东西。
3. 切分只动确认过的包：日期前缀匹配 ^202[0-9]{5} 的才进归档目录，其余一律跳过。
4. 删除走两段：先 move 到 _trash/，挂 48 小时再真删。这 48 小时里要是有下游来捞文件，还能捞回来。

实测数据

拿 6 台机子（Win10 22H2 / Win11 23H2 混合）跑同一份 12GB 日志包：

关键收益不是速度，是预检把误删概率从「偶尔」压到「零」。之前每月要花两小时手动整理日志目录，现在脚本跑完我只扫一眼告警邮件，每月省下来的两小时是实打实的。

目录白名单这里再强调一遍

脚本里涉及 move 或 del 的路径，白名单必须整目录加，别只写文件前缀。我吃过亏：只写了 D:\logs\app，结果 D:\logs\app-20250301 这种同级目录没被排除，差点被当旧包清掉。后来改成 D:\logs\app\ 带尾斜杠，再加一层路径规范化校验才踏实。

适合谁

• 如果你只是普通用户，偶尔手动解压一两个包，用 Win解压缩 图形界面就够，速度快、上手简单，没必要折腾批处理。
• 如果你跟我一样每天面对几十个日志包和部署包，要定时切分归档、要留审计痕迹，那 7-Zip 命令行 + 批处理这套组合目前还是最稳的，虽然写起来麻烦，但每一步都能对账。

想问问大家

你们做日志归档时，预检和删除之间还卡了什么校验？我现在只有完整性 + 行数两道，总感觉还缺一道——比如文件时间戳连续性，但没想好怎么在批处理里低成本实现。有跑过类似流程的，评论区给个思路。