System.exit()的状态码遵循POSIX约定：0表示成功，非零表示失败；应严格限定在0–127范围内，避免截断错误；在Spring、Web容器和测试中禁用，改用优雅退出机制。

System.exit() 的状态码不是 Java 自己定的，而是沿用操作系统（尤其是 POSIX 兼容系统）的通用约定：0 表示成功，非零表示失败。这个数字会真实传递给父进程或 shell，被脚本、CI/CD 流水线、容器编排（如 Kubernetes）用来判断程序是否“按预期结束”。用错状态码，下游就可能误判运行结果。

0 和非零：最核心的语义分界

状态码 0 是唯一被广泛识别为“成功”的值。几乎所有 shell 脚本都用 if [ $? -eq 0 ] 判断上一条命令是否成功；CI 工具默认把非零退出当作构建失败；Kubernetes 的 liveness/readiness probe 也依赖它做健康决策。一旦返回非零（哪怕只是 1），就等同于向外界宣告：“这次执行没完成预期目标”。

• 0 不代表“没出错”，而代表“完成了该做的事”——比如命令行工具正确输出帮助信息后退出，就该用 0
• 非零不等于“崩溃”，而是“未达成目标”——参数校验失败、文件找不到、网络超时，都该用不同非零值区分
• 不要用 0 掩盖问题：比如 catch 到异常却仍调 System.exit(0)，会让监控和运维完全无法察觉故障

状态码取值范围与平台截断规则

Java 本身不限制 status 参数大小，但操作系统只保留低 8 位（0–255）。超出范围的值会被自动截断，容易引发隐性错误：

• 负数如 System.exit(-1) → shell 中 $? 显示为 255（因为 -1 & 0xFF = 255）
• 大于 255 的数如 System.exit(256) → 截断为 0，看似成功，实则掩盖严重错误
• 建议严格限定在 0–127：0 表示成功；1–127 用于自定义错误（如 1=通用错误，2=IO 错误，10=配置缺失）

Web/Spring/测试环境中的禁用场景

在托管环境中硬杀 JVM，会跳过关键清理逻辑，造成资源泄漏或状态不一致：

• Spring Boot 应用里调 System.exit()，会绕过 @PreDestroy、事务回滚、连接池关闭，甚至导致注册中心残留无效实例
• JUnit 测试中使用，会使整个测试套件中断，后续用例不再执行；应改用 Assert.fail() 或抛出测试专用异常
• Servlet 容器（Tomcat/Jetty）中禁止调用，否则可能卡住线程池、丢弃未 flush 的日志、遗漏 shutdown hook

更安全的替代方案

多数时候你不需要“杀死 JVM”，只需要“退出当前执行流并告知结果”：

• 命令行工具主函数：用 return 让 main 自然结束，JVM 默认以 0 退出；出错时抛出自定义异常，在顶层捕获后打印提示并返回对应非零码
• Spring Boot 应用：用 SpringApplication.exit(context, exitCode) 触发优雅关闭流程，支持自定义退出码和回调
• 微服务下线：先调用 Nacos/Eureka 注销接口，再关闭 WebServer，最后让 JVM 在 SIGTERM 信号下自然终止，而非主动 System.exit()