压缩包解压到一半报错，我拿三个包对比才发现是文件名长度惹的祸

上周部署一个老项目，从运维那拿了个日志归档包，解压到一半直接报错退出，提示「路径过长」。我第一反应是磁盘满了，df 一看还剩 80G，排除。又怀疑是包损坏，md5 对了两遍一致，也排除。

真正动手排查是从换工具开始的。同一个包，我用 Win解压缩 解，直接弹窗说某些文件无法创建；换 7-Zip 命令行 7z x，报错更明确：Cannot create file : Filename too long。这才把方向锁定在文件名长度上。

拆开看，包里有几层嵌套目录，最深的路径拼起来超过 260 个字符，Windows 默认 API 就卡在这。有意思的是，三个不同来源的包表现还不一样：

• 包 A：纯英文路径，超长但 Win解压缩 能解出来，7-Zip 也没问题
• 包 B：中英混排，Win解压缩 解到一半报错，7-Zip 报「文件名过长」
• 包 C：带日文假名，两个工具都挂，但 7-Zip 的报错能定位到具体文件

这里有个细节值得说：Win解压缩 报错时只弹一个笼统的「解压失败」，不告诉你哪个文件出的问题；7-Zip 命令行会把具体路径打出来。对我这种要批量处理日志包的人来说，能定位到文件比解压快那零点几秒重要得多。

我的处理办法是解压前先扫一遍包内路径长度。用 7-Zip 的 7z l -slt 列出所有文件路径，配合 awk 过滤超过 240 字符的条目，提前把超长目录改名或者改用 \\?\ 前缀路径解压。如果是 Win解压缩 用户，最省事的办法是解压目标目录别选太深，比如直接解到 D:\tmp\ 下面，能避开不少坑。

另外提醒一句：这种超长路径的包，解压后最好再跑一次文件数对比。我有次解压「成功」了，但实际少了 3 个文件，就是路径太长被静默跳过了。

你们处理日志包的时候，有没有遇到过这种「解压成功但文件不全」的情况？都是怎么校验的？