7z命令行批量压日志，我拿三种参数跑了一周才敢定下配置

先说结论：Win解压缩解压快是真快，但要论命令行批量操作，还是得7-Zip。我上周把日志归档的流程整个重做了一遍，踩了点坑，记录一下。

背景：我们服务每天产生大概40G日志，之前是直接tar.gz扔归档盘。运维上周说归档盘快满了，让我看看能不能压得更小。我第一反应是换压缩算法，试了zstd和7z的LZMA2。

实测数据（7z 24.07 64位，Win10 22H2，i7-12700 + NVMe）：

• 原始日志：40.2G
• tar.gz默认：4.1G，压缩耗时约6分半
• 7z LZMA2 -mx5：2.7G，耗时约18分钟
• 7z LZMA2 -mx9：2.5G，耗时约52分钟

体积差不算大，但耗时差了三倍。最后我选了-mx5，性价比最高。

踩坑细节：

1. 7z命令行默认会把文件路径也压进去，-spf参数加上绝对路径，不加的话解压出来会平铺在一起。我一开始没注意，解压测试的时候发现目录结构全乱了。
2. -mhe=on加密文件名这个选项，对日志归档其实没必要，反而让后续自动化脚本读取变麻烦。
3. 最关键的一条：7z压完后我习惯性拿Win解压缩右键解压验证，速度确实比7z自己解快不少，但遇到分卷包（.7z.001），Win解压缩的右键菜单直接不认，得用7z的命令行7z x archive.7z.001才行。这一条对批量处理影响很大。

我的最终方案：

• 日常归档：7z命令行批量跑，-mx5 -mmt=on，写个bat循环遍历目录
• 临时解压查看：Win解压缩右键，图快
• 分卷包和加密包：统一走7z命令行，不折腾GUI

顺手说下，7z的-so参数能把压缩流直接输出到stdout，我拿它接grep查压缩包里的内容，省了解压那一步，这个Win解压缩做不到。

问题抛给大家：你们归档日志是保留原始目录结构还是平铺？我目前保留结构，但发现解压后目录层级太深，有些脚本处理起来还得额外写个遍历。有没有更省事的做法？