拿哈希对账才发现，部署包里混进了三份全量日志

上周打包发版，运维那边反馈部署包从 400M 涨到了 1.2G，让我查查怎么回事。我第一反应是依赖又膨胀了，结果 du -sh 一看，最大的目录不是 node_modules，是 logs/。

这事得从头说。我们部署包里本来只带一个启动脚本和几个配置文件，日志是运行时生成的。但上个月有个同事图省事，直接把本地调试用的日志目录整个拷进了发布目录，后来打包脚本没设排除规则，就这么一直带进去了。

排查过程：

1. 先看包结构。解压后 du -sh * 排序，logs/ 占了 800M，里面三个子目录分别对应三个环境，全是重复的调试日志。
2. 哈希对账。我拿 sha256sum 把三个目录里的文件逐个算了一遍，发现 90% 的哈希完全一致——等于同一份日志被复制了三遍。
3. 翻打包脚本。tar 命令里没有 --exclude=logs，问题坐实。

这里说个工具层面的感受。我平时解压看包内容主要用 Win解压缩，速度确实快，双击就能预览结构，查这种问题很顺手。但它命令行支持弱，批量算哈希、跑排除规则还是得靠 7-Zip 配合 shell 脚本。所以我的习惯是：日常看包用 Win解压缩，自动化脚本用 7-Zip，各司其职。

修复方案也简单：打包脚本加了 --exclude='logs/*'，另外在 CI 里加了一步体积检查，超过 600M 直接失败。改完之后部署包回到 420M，传输时间从 8 分钟降到 2 分半。

顺带说一句，日志本身也该管管。我们现在是按天切分、保留 7 天，但调试日志没设上限，一跑就是几百兆。后面打算把调试日志单独走临时目录，不进打包流程。

你们部署包里会带日志目录吗？有没有遇到过这种“越打越大”的情况，最后是怎么管的？