在Appveyor环境部署时遇到Central Directory损坏问题求助

我之前碰到过类似的部署故障，结合你描述的场景（同一包在Test环境正常部署，UAT首次出现Central Directory损坏），给你几个实际可行的排查思路：

• 先排除网络传输的问题：
  虽然zip包在构建代理服务器上是完好的，但从构建机传到UAT服务器的过程中可能出现丢包、中断或者传输工具的bug。你可以手动把构建机上的那个zip包拷贝到UAT服务器，然后手动执行解压/部署操作，如果手动操作能成功，那大概率是自动化部署的传输环节出了问题。比如检查Appveyor部署脚本里的传输命令（像scp、robocopy这类）有没有启用校验，或者是否存在网络波动导致的部分文件传输不完整。

• 检查UAT环境的解压工具差异：
  Test和UAT环境的解压工具可能不是同一个版本，甚至不是同一款工具。有些旧版本的unzip或者Windows下的解压工具，对某些压缩格式（比如带LZMA2算法的zip）的兼容性不好，会误报Central Directory损坏。你可以在UAT服务器上直接运行unzip -t your-package.zip（Linux）或者用系统自带的解压工具手动解压，看看能不能正常完成，同时对比Test环境的解压工具版本和配置。

• 对比Test与UAT的部署脚本差异：
  别忽略脚本的细节——哪怕是同一包，部署到两个环境的脚本可能有细微差别。比如是否在UAT部署流程里加了额外的步骤：比如对zip包进行重命名、追加文件，或者解压命令用了错误的参数（比如unzip的某些参数会破坏zip结构）。仔细检查Appveyor的部署配置，对比Test和UAT的部署步骤，看有没有针对UAT的特殊操作导致zip包被篡改。

• 排查UAT服务器的磁盘与权限问题：
  有时候看似是zip损坏的错误，实际是UAT服务器的目标磁盘空间不足，或者部署目录的权限不够，导致解压过程中无法完整读取zip的Central Directory信息。你可以先检查UAT部署目录的磁盘剩余空间，再确认运行部署脚本的用户是否有该目录的读写权限——权限不足时，解压工具可能会抛出误导性的错误信息。

• 验证zip包的完整性：
  构建成功后，zip包可能被构建代理上的其他进程意外修改，或者部署脚本重复使用了旧的缓存包。你可以在构建完成后计算zip包的MD5/SHA哈希值，然后在UAT部署前再次计算该包的哈希，对比两者是否一致。如果不一致，说明包在构建后到部署前的环节被篡改了，需要排查构建代理上的进程或者缓存机制。

内容的提问来源于stack exchange，提问作者Rui