system.exit(0)表示成功退出，非零值表示异常终止；状态码会被操作系统截断为0–255范围，负数转为255、256变0；web/spring/测试中禁用，应改用抛异常、return或springapplication.exit()等优雅方式。
System.exit() 的状态码到底传多少才对
状态码不是随便填的数字，System.exit(0) 表示成功退出，非零值（比如 1、-1）表示异常终止——这是操作系统层面的约定，Java 本身不校验，但 shell 脚本、CI 流程、容器健康检查全靠它判断程序是否“真的跑完了”。
-
0是唯一被广泛认为“正常”的值；用System.exit(42)或System.exit(999)在 Linux 下完全合法，但下游脚本可能只检查是否为 0，其他值一律当失败 - 负数如
-1会被 shell 截断为无符号字节：在 bash 中java MyApp; echo $?输出的是255（因为 -1 & 0xFF = 255），不是 -1 - 超过 255 的值（如
256）也会被截断：256 % 256 == 0，结果变成 0，看似成功，实则掩盖问题
什么时候不该用 System.exit()
它会立刻终止 JVM，跳过所有 finally 块、钩子函数（Runtime.addShutdownHook()）、未 flush 的日志缓冲区——在 Web 容器、Spring Boot 应用、单元测试里调用，大概率导致资源泄漏或测试假阳性。
- Web 服务中遇到错误，应该抛出异常让框架处理，而不是
System.exit(1) - JUnit 测试里调用
System.exit()会让整个测试套件中断，后续测试不执行；要用SecurityManager拦截或改用SystemExitSecurityManager类模拟 - 有
Runtime.addShutdownHook()时，System.exit()会触发它，但若 JVM 正在崩溃或被kill -9，钩子也不会运行——别把它当可靠清理手段
替代 System.exit() 的更安全做法
多数场景下，你真正需要的不是“杀掉进程”，而是“优雅退出当前逻辑流”。直接 return、抛受检异常、或者用应用级退出信号，比硬杀 JVM 更可控。
- 命令行工具主函数中，用
return代替System.exit()，让 main 方法自然结束；JVM 会自动以 0 状态退出 - 需要传递错误原因时，抛出自定义异常（如
CommandLineException），由顶层捕获并打印帮助信息，再返回非零状态——Spring Boot 的SpringApplication.exit()就是这么干的 - 微服务中想“下线”，应调用注册中心的注销接口 + 关闭端口监听，而不是
System.exit()；K8s 会等 readiness probe 失败后再发 SIGTERM
调试时怎么确认 exit 状态真被收到了
别只看控制台有没有输出，要验证操作系统拿到的确实是你要的值。不同环境行为差异很大，尤其 Windows cmd 和 WSL 的处理就不一样。
立即学习“Java免费学习笔记（深入）”；
- Linux/macOS 下，执行后立刻运行
echo $?；注意：如果中间穿插了管道或后台任务（如java MyApp && echo "done"），$?取的是前一个命令的退出码，不是 Java 进程的 - Windows cmd 中，
%ERRORLEVEL%可读取，但 cmd 对大于 127 的值支持不稳定；PowerShell 用$LASTEXITCODE更准 - IDE（如 IntelliJ）里运行时，退出码常被 IDE 拦截或忽略；必须在终端里手动执行 jar 包才能测真实行为
状态码这事看着简单，但跨平台、跨环境、跨调用链时，一个错位的 127 或 0 就能让自动化部署卡在“以为失败”或“以为成功”的死循环里。
