公司部署包体积三个月涨了8个G，我拿哈希对比才找出是哪个模块在偷偷膨胀

最近在整部署包，发现一个挺邪门的事：同一个项目的部署包，三个月前还是 210MB，现在直接干到 8.2GB。运维那边天天催我优化，说我每次发版像在传电影。

我先质疑再对账，不能光看总体积就瞎猜。于是把最近 6 个版本的部署包全解压了，逐个目录算哈希和体积，列了张表。结果很明确：膨胀的几乎全在 assets/ 和 lib/ 两个目录里。

具体数据：

• assets/ 从 40MB 涨到 5.1GB，主要是历史版本的静态资源没清理，每次发版都往里塞一份新的，旧的没删。
• lib/ 从 80MB 涨到 2.3GB，里头有 14 个依赖包的 .so 文件，每个平台各带一份，但实际线上只用 linux-x64。

再细看，assets/ 里重复率极高，我用 sha256 对同名文件做了去重统计，发现 72% 的图片和字体文件是完全一样的，只是散落在不同版本目录里。

处理方式不复杂：

1. 构建脚本里加了清理步骤，每次打包前先清空 assets/ 下的历史版本目录，只保留当前版本引用到的资源。
2. 依赖库按目标平台裁剪，只把 linux-x64 的 .so 打进部署包，其他平台的移到单独的可选包。
3. 打包后用 tar -tvf 或 unzip -l 对比上一次的清单，体积增量超过 5% 就告警。

改完之后部署包回到 340MB，发版速度肉眼可见地快了。不过我也留了个心眼：裁剪平台依赖这块，得确认测试环境的架构跟线上一致，不然容易出幺蛾子。我们测试机是 arm 的，打包机是 x86，差点又踩坑，最后是在构建脚本里显式指定目标平台才稳的。

问一句：你们部署包膨胀一般是哪个目录先露馅？有没有人用体积增量告警卡过发版流程，阈值一般设多少合适？