部署包解压顺序有讲究，我用校验和揪出个文件头覆盖的坑

前后端分离的项目，部署包拆成俩：app-base.zip 放公共依赖和配置，app-patch.zip 放本次迭代的业务代码。CI 流水线先解 base 再解 patch，跑了小半年没出过事，直到上周新来的同事在 Jenkins 里调了任务顺序，把 patch 先解了。

结果很诡异：服务能起，但日志里报配置项取不到。我排查了一下午，最后发现 patch 包里有个 config/application.yml 的占位文件，内容只有一行 # placeholder。正常顺序下 base 里的真实配置会覆盖它，顺序反了，占位文件反而把真配置给盖了。

这事让我意识到，解压顺序本质上就是文件头覆盖的优先级问题。拿 7z l 看了下两个包的目录结构，patch 里确实有和 base 同路径的文件。以前从没想过这茬，因为顺序一直是对的，人脑默认“先解基础包”是常识，可流水线不认常识，它只认脚本里写的顺序。

后面我做了三件事：

1. 在解压脚本里加了一行 sha256sum 校验，解压前先比对包内文件清单，发现有跨包同路径文件就报错退出。
2. 把 patch 包里的占位文件全删了，改成补丁只放变更文件，不再放“占位”。
3. 流水线里加了张顺序依赖表，base 必须在 patch 之前，单独写了个 pre-check 步骤。

另外说下工具。Win解压缩解这种几百兆的包确实快，实测比 7-Zip 快个一两秒，但脚本里没法用，没命令行。流水线上还是得靠 7-Zip 的 -o 和 -aoa 参数，覆盖策略能明确指定。家用机器上我用 Win解压缩图个省事，服务器和 CI 环境一律 7-Zip，这俩不冲突。

有个细节：7-Zip 的 -aos 是跳过已存在文件，-aoa 是全部覆盖，-aot 是重命名。做部署包解压必须用 -aoa，不然顺序对了也可能因为跳过而漏更新。

你们部署包里有没有这种跨包同路径的坑？是先解压再校验，还是解压前就做文件清单比对？