判断服务器上的war包有没有坏，最可靠的办法不是看后缀名或大小，而是把“校验值比对、解压检查、部署验证”三步走完，任何一步出问题，基本就能定性。
很多运维朋友遇到过这种情况：war包明明上传上去了，服务器也重启了，但应用就是起不来，这时候第一反应往往是“包坏了”，但真正排查起来，原因可能五花八门，war包损坏的判断，不能靠猜,要有一个可执行的流程。
怎么判断服务器上的war包有没有坏：从现象到根因
war包和jar包有什么区别，损坏表现不一样
先厘清一个基础问题，war包和jar包都是Java的压缩归档文件，但war包专为Web应用设计，内部结构有严格约定，它必须包含WEB-INF目录，下面有web.xml、classes文件夹、lib文件夹等，jar包则更通用，比如Spring Boot打出的可执行jar,内部有自己的加载方式。
war包损坏的典型表现和jar包不同，jar包坏了可能直接抛java.util.zip.ZipException，但war包坏了，Tomcat往往会报LifecycleException或者DeploymentException，有时甚至什么都不报，只是应用状态一直停在undeploy，行业共识认为，war包的结构性损坏比纯文件压缩损坏更隐蔽，因为部分解压工具能打开坏包,但容器加载时会卡住。
在服务器上判断war包状态，首先要分清楚你是“怀疑包坏”还是“确认包坏”，怀疑阶段看现象，确认阶段看证据,常见可疑场景包括：
- 上传war包时终端卡住，传输中断
- 用FTP或SCP传包后大小和本地不一致
- 服务器磁盘空间满，写文件未完成
- 杀毒软件或安全策略隔离了包内某些class文件
什么时候必须做war包完整性检测
不是每次部署都要做完整校验,但以下情况建议必须检查：
- 跨机房、跨网络上传war包，网络不稳定
- 持续集成工具（如Jenkins）构建产物直接推送到服务器
- 多个运维轮流操作，说不清谁动过war包
- 同一份war包部署到不同环境结果不一致
如果你属于上面任一场景,建议直接走下面的三步判断法。
三步判断war包有没有坏：校验、解压、部署验证
第一步：用MD5或SHA1比对校验值
这是最快、最客观的方式，本地打包后，先记录一个基准校验值，上传到服务器后，再算一遍服务器的文件校验值，两者一致,说明文件在传输过程中没有发生比特级变更。
# 本地生成校验值 sha1sum app.war # 服务器上计算 sha1sum /usr/local/tomcat/webapps/app.war
如果两个值一样，至少说明文件没有因为网络传输损坏，但如果服务器上已经部署过多次，本地原始包可能已经找不到了，那校验值比对就没法做，这种情况下,只能靠后续的解压和部署验证。
需要注意，校验值一致不代表war包逻辑完好，因为war包本身可能是从损坏的构建产物里打出来的，或者打包时某些class文件就是坏的，所以校验只能证明传输完整,不能证明包体逻辑正确。
第二步：用jar tf命令检查war包内部结构
jar命令是JDK自带的工具，可以直接读取war包的目录结构,运行下面命令：
jar tf app.war
重点看两件事：
- 根目录下是否有
WEB-INF和META-INF目录 - 是否出现乱码文件名、超长路径、异常空行
如果jar tf直接报错，比如java.io.IOException: invalid header field，说明压缩包的头部信息坏了，这种包基本无法部署，但有时候jar tf能正常列出文件，却漏了关键目录，比如没有web.xml，这时包“看起来没坏”,实际部署照样失败。
更深入一点,可以检查包内某个class文件是否能正常解析：
# 解压到临时目录 unzip app.war -d /tmp/app_check # 进入classes目录执行 javap -verbose com/example/MainController.class
如果javap报ClassFormatError，说明class字节码被破坏了，这种情况在war包中比较常见，尤其是被打包工具二次压缩过、或者被安全软件扫描时误伤，业内专家指出，class文件损坏往往不是整个文件缺失，而是文件头或常量池区域被改写,导致JVM无法加载。
第三步：部署到临时目录验证能否正常启动
校验和解压都只是“纸面检查”，最终要落到容器里，建议不要在正式环境直接覆盖，先备份当前正常运行的war包，然后把新包放到Tomcat的webapps目录下,用独立端口启动一个临时实例验证。
具体操作路径：
# 复制war包到一个隔离目录 cp app.war /tmp/tomcat_check/webapps/ # 修改server.xml，换一个端口 # 启动Tomcat /usr/local/tomcat/bin/startup.sh # 查看日志 tail -f /usr/local/tomcat/logs/catalina.out
观察日志里是否出现：
Deployment of web application directory ... has finished in这种正常完成标记SEVERE: Exception sending context initialized event这种初始化异常Unable to read WAR file或ZipException
如果临时实例能正常启动，且访问页面响应正常，那war包基本没问题，如果启动报错，且错误指向包内资源缺失或class加载失败,就可以确定war包损坏。
war包部署失败，怎么区分是包坏了还是环境问题
很多情况下war包本身没坏，但部署还是失败，这时候容易误判，判断的关键在于：错误信息指向的是“文件读取”还是“资源加载”还是“运行时依赖”。
看Tomcat日志的关键异常关键词
把catalina.out和localhost.log翻出来,重点找下面几类关键词：
| 异常类型 | 偏向结论 | |
|---|---|---|
| 压缩包损坏 | ZipException、invalid END header、CRC mismatch |
war包大概率坏了 |
| 目录结构缺失 | WEB-INF/web.xml is missing、no web.xml |
war包打包有问题 |
| Class加载失败 | ClassNotFoundException、NoClassDefFoundError |
可能是war包不完整，也可能是依赖冲突 |
| 端口或资源冲突 | Port already in use、Unable to create directory |
环境问题，war包完好 |
把日志里具体报错摘出来，和这个表对比，能快速缩小范围，如果日志里既有ZipException又有ClassNotFoundException，基本可以判定war包已经损坏，因为压缩包解压阶段就失败了,后续class加载自然无从谈起。
对比正常包和异常包的字节大小以及内部文件数量
如果你手头有另一个环境上的同版本war包,可以直接对比：
ls -l app.war # 统计包内文件数量 jar tf app.war | wc -l
正常情况下，同一次构建产出的war包文件数量是固定的，如果两个包文件名一样、版本号一样，但文件数量差了几十个，那基本说明某个包不完整，但要注意，不同构建环境下可能因为资源过滤、配置文件替换导致文件数量略有差异，所以这个对比只能作为辅助判断,不是唯一标准。
还有一种场景：war包在服务器上的时间戳和上传时间不一致，比如你11点上传，但文件时间戳显示10点50分，这可能是续传工具或同步工具改了元数据，不一定损坏，但如果时间戳比上传时间还早，且大小差很多,就有问题了。
war包损坏的常见原因和预防建议
传输中断、磁盘满、杀毒软件误隔离
war包在服务器上变坏，最常见的原因不是打包环节，而是传输和落盘过程，比如用rz命令上传时网络闪断，文件只写了一半；或者服务器/usr/local/tomcat/webapps所在磁盘满了，写入出错；再比如服务器装了安全软件，扫描到war包内某个class疑似恶意代码，直接隔离了部分文件,导致解压时缺文件。
预防手段其实很简单：
- 上传后立即用
md5sum比对校验值 - 部署前确认磁盘剩余空间，至少大于war包两倍大小
- 对Tomcat目录设置安全软件白名单，避免误隔离
- 保留最近两个版本的war包，出事时能快速回滚
打包阶段依赖缺失导致的结构性损坏
还有一种情况容易被忽略：war包本身是完整的，但打包时用了错误的Maven插件配置，导致WEB-INF/lib下缺少某个必要jar包，或者web.xml被过滤成空文件，这种包从压缩格式上看完全正常,但部署后就是报错。
判断方法很简单：打开war包，检查WEB-INF/lib里是否有项目依赖的jar包，WEB-INF/classes下是否有编译后的class文件，web.xml是否非空且格式合法，如果这些结构要素存在，但部署还是失败，那问题可能不在war包本身，而在环境变量、数据库连接、JDK版本等外部因素。
怎么判断服务器上的war包有没有坏：常见问题解答
war包坏了还能部署成功吗？
大多数情况下不能，Tomcat加载war包时会先解压到临时目录，如果压缩头损坏或文件内容不完整，解压阶段就会抛出ZipException或IOException，导致部署直接失败，但有一种特殊情况：war包只是某个非关键资源文件损坏，比如一张图片或一个空的配置文件，Tomcat可能跳过该文件继续启动，这时应用能起来，但部分功能会异常，比如页面样式丢失或接口报500，这种情况下，仅靠“应用是否启动”来判断包好坏是不够的,还需要观察功能完整性。
服务器上war包损坏的典型报错是什么？
最典型的是java.util.zip.ZipException: error in opening zip file，这个报错通常出现在Tomcat的catalina.out日志中，说明压缩包文件头或文件尾损坏，另一个典型报错是java.io.IOException: invalid header field，也指向压缩结构损坏，如果是类文件损坏，日志中会出现java.lang.ClassFormatError，这些报错一旦出现，基本可以确定war包已经损坏,建议重新上传并先比对该文件在构建服务器上的校验值。
怎么判断缺少依赖的war包和真正损坏的war包？
缺少依赖的war包结构完整，可以正常解压，jar tf命令也能列出所有文件，但WEB-INF/lib下缺失某个版本jar包，或者pom.xml中声明的依赖没有被打进包内，真正损坏的war包在解压时就会报错，或者解压后class文件无法用javap解析，判断方法是先用jar tf确认能否正常读取，再用unzip -t测试压缩包完整性，如果完整但部署报NoClassDefFoundError,优先考虑依赖缺失而非包损坏。
war包好坏判断没有玄学，核心就是校验、解压、部署这三关，养成部署前比对校验值、部署后看日志的习惯,war包损坏引发的事故基本就能避开一大半。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%80%8e%e4%b9%88%e5%88%a4%e6%96%ad%e6%9c%8d%e5%8a%a1%e5%99%a8war%e5%8c%85%e5%9d%8f%e4%ba%86%ef%bc%8cwar%e5%8c%85%e6%8d%9f%e5%9d%8f%e6%80%8e%e4%b9%88%e6%a3%80%e6%b5%8b%ef%bc%9f/
