拿脚本循环解压两千个日志包，才发现Win解压缩的「智能解压」有多坑

上周处理一批生产环境日志，两千多个 .zip 包，按天分目录，每个包几十到几百 MB 不等。我本来想用 7-Zip 命令行一把梭，结果发现有几个包 7z 报错但 Win解压缩 能正常解开，就顺手把 Win解压缩 也拉进来做对比测试。

测试环境：Win11 23H2，i7-12700H，32G 内存，NVMe 盘。7-Zip 24.08 命令行版，Win解压缩 5.9.8 普通版。

先说结论：

1. Win解压缩 的「智能解压」在批量场景下反而拖后腿。它会自动判断压缩包类型、尝试识别编码、检查是否分卷，这些逻辑单次用感觉贴心，但两千个包累计下来，平均每个包多花 1.2 秒左右。7-Zip 命令行直接 7z x -o<dir> 走起，没有额外判断。
2. 但 7-Zip 在几个包上确实翻车了：文件名是 GBK 编码，7z 解出来是乱码，Win解压缩 能正确识别。这属于压缩包本身不规范，但生产环境里你没法要求上游改。
3. 速度上，纯解压操作 7-Zip 命令行平均比 Win解压缩 快 15% 左右，没到「碾压」程度。之前社区有人提到 40% 差距，我猜是跟包内文件数量和是否分卷有关。

我的土办法：

写了个 PowerShell 脚本，先用 7z 跑一遍，对报错或文件名乱码的包，再调 Win解压缩 的命令行参数（它其实支持 /x 静默解压，只是文档里没明说）兜底。这样两千个包跑下来，总耗时比纯用 Win解压缩 少了约 18 分钟，比纯用 7z 只多了 4 分钟，但一个包都没漏。

踩坑细节：Win解压缩 命令行有个 /y 参数表示全部覆盖，但遇到目标目录已存在同名文件时，它不会像 7z 那样跳过而是直接覆盖，我差点把前一天解出来的日志覆盖掉，后来加了时间戳目录才解决。

给同样要批量解日志的兄弟建议：

• 别迷信单一工具，7z 做主、Win解压缩 做补是最稳的
• 解压前先抽样看编码，file 命令或直接试解一个包
• 脚本里加上失败重试和日志记录，别指望一次全过

最后问一句：你们处理 GBK 编码的压缩包时，有没有遇到过 7z 解出来文件名正常但内容乱码的情况？我遇到两个包是这样，还没想明白为啥。