部署包体积突然涨了200M，哈希对账揪出CI缓存没清

上周五发版，运维那边甩过来一句「包怎么又大了」，我一看构建产物，比上个版本多了 200M 出头。按老规矩，先别急着删东西，拿哈希对账。

先说环境

• 构建机：Jenkins 2.401，Ubuntu 22.04
• 打包脚本：自己写的 shell，tar.gz 走 tar -czf
• 对比工具：sha256sum + sort 对账

排查步骤

1. 把上一版和这一版的 tar.gz 都解到临时目录，分别跑 find . -type f -exec sha256sum {} \; | sort -k2，输出两个清单。
2. 用 comm -13 old.txt new.txt 看新增文件，再用 comm -23 看删掉的。
3. 第一步就暴露了：target/cache/ 底下多出来一堆 .jar，时间戳全是构建当天的。

根因
CI 里有个 mvn -o 的离线缓存目录，之前一直靠 mvn clean 顺手清掉。上个月有人把 clean 阶段挪到 parallel 分支里去了，主构建路径根本跑不到，缓存就跟着打进包里了。200M 里 180M 是重复的依赖 jar，剩下的是没清掉的测试报告。

判断依据

• 新增文件 90% 集中在 cache 目录，且哈希与仓库里已有 jar 一致，属于纯冗余。
• 包体积增量与 cache 目录大小基本吻合，误差在 5M 以内。
• 拿两台构建机各跑一遍，增量一致，排除单机偶发。

怎么改的

1. 打包脚本里加白名单，只打 dist/ 和 conf/，其他一律不进 tar。
2. 构建完自动跑一遍体积阈值检查，超过上一版 10% 就告警。
3. 对账脚本顺手留成 Jenkins 的 post 步骤，每次出个文件清单快照，方便下次比对。

踩坑提醒
别光看总大小，tar.gz 压缩率受文件类型影响大，同样的文件换个顺序打包体积都能差几 M。对账时最好先解包再算哈希，别直接比压缩包。

你们构建产物里有没有那种「看着不该在、但一直没人管」的目录？我这回是 cache，之前还碰到过日志目录跟着打进包的，想听听大家怎么设白名单的。