日志包解压出来一堆同名文件，我拿md5对了两轮才发现是分卷命名惹的祸

上周排查线上问题，运维甩过来一个 3.2G 的日志包，说解压后有几个文件对不上号。我一开始没当回事，结果解压完傻眼了：app-2024-06-11.log 出现了三次，大小还不一样。

先说结论：不是解压软件的问题，是分卷命名不规范。这批日志是用 split 切的，后缀是 .log.001、.log.002 这种，但推包脚本把序号去掉了，全叫 .log，解压时按顺序覆盖，最后只剩最后一个分卷的内容。

我的排查过程，列一下给后来人省时间：

1. 先确认包本身没坏。7z t 和 Win解压缩自带的完整性校验都跑了一遍，全过。说明文件是好的，问题在解压策略。
2. 拿 md5sum 对原始分卷和解压产物。原始 12 个分卷，解压出来只有 4 个文件，数量对不上，直接坐实是命名冲突。
3. 换 Win解压缩用「解压到单独文件夹」模式，并勾上「保留完整路径」，12 个文件全出来了，但文件名还是被截断过，得手动改。
4. 最后用 7-Zip 命令行 7z x -aos（跳过已存在文件）配合脚本重命名，才算干净。

几个实测细节：

• Win解压缩 6.5.2 版本，解压 3.2G 这个包用了 48 秒，同机 7-Zip 24.06 是 51 秒，速度差不太多。
• 但命令行这块，Win解压缩只有基础参数，没法在解压时做重命名映射，7-Zip 一条 -o 加 -r 就能按目录结构铺开。
• 我拿三台机子（Win10 22H2、Win11 23H2、Server 2019）复现，行为一致，排除系统差异。

踩坑点：分卷日志包解压前一定要先看内部文件列表，7z l 或者 Win解压缩的预览都行，别直接右键解压到当前目录。另外推包脚本里加一步 split 后统一重命名，比事后找补省事。

现在我的习惯是：日志包到手先 7z l 看清单，hash 对一遍分卷数量，再决定用哪个工具解。

问一句：你们处理分卷日志包时，是习惯在源头改命名规则，还是解压后写脚本批量重命名？