部署包解压顺序乱了一次后，我给解压流程加了三道校验

上个月打包部署，踩了个不大不小的坑。

背景：我们的部署包结构是 config/ 下面按环境分目录，里面有个 application.properties 和一堆按模块拆的 *.yml。打包脚本用 zip 扫目录，本来以为解压出来顺序无所谓，反正最后读的是合并后的配置。

结果在测试环境翻车了。某个模块的 yml 里写了 spring.datasource.url 的覆盖值，解压后文件头排序跟打包时的目录遍历顺序对不上，配置加载器按文件名排序读，直接读到了旧值。本地跑没事，因为本地是文件夹不是压缩包。

报版本号：Win解压缩 5.6.2（公司统一装的），7-Zip 24.07，Bandizip 6.2.1。三台机器（Win10 22H2 一台、Win11 23H2 两台）分别解压同一个包，用 PowerShell Get-ChildItem | Sort-Object Name 对文件列表做 diff，Win解压缩和7-Zip出来的文件顺序一致，但跟打包机上的源目录顺序都不一致。Bandizip 有个「保留目录结构」选项，开了之后顺序更接近源目录，但也不是完全一致。

结论很明确：不能指望解压工具给你保留打包时的逻辑顺序。文件头排序是压缩格式决定的，跟工具关系不大。所以我在部署流水线里加了三道校验：

1. 打包时生成 manifest：find . -type f | sort > manifest.txt 一起打进包里，解压后先比对文件清单，数量、路径、大小对不上直接中止。
2. 解压后强制按 manifest 顺序处理：配置合并脚本读 manifest，不依赖文件系统遍历顺序。
3. 加一步 md5 对账：对 config/ 下所有文件算 md5，跟打包时记录的哈希比对，顺序错乱导致内容被覆盖也能发现。

这三步跑下来，解压环节的意外基本清零了。对普通用户来说 Win解压缩 确实够快够省心，但做部署这种对顺序和完整性较真的场景，还是得自己把校验补上——工具不背这个锅，是流程得自己兜住。

问一句：你们部署包里如果有多个配置文件，是靠命名规范（比如 01-xxx、02-xxx）来保证加载顺序，还是在代码里写死优先级？