System.exit() 仅原样传递退出码给操作系统，需确保值在0–255范围内：0表示成功，1–125用于业务错误分层，避免负数、126–127及128+预留码；退出前须完成资源清理；容器环境中应使用框架提供的退出方法而非直接调用。
System.exit 本身不“控制”异常退出码，它只是把传入的整数原样交给操作系统——真正决定退出码是否合理、是否能被正确识别的，是你传什么值、在哪调用、以及运行环境怎么解释它。
退出码必须落在安全范围内
操作系统只认 0–255 的整数，超出或负数会被截断或映射，容易误导外部流程：
- 0 是唯一公认的“成功”码，Shell 脚本、Kubernetes 探针、CI/CD 都靠它判断是否继续执行
- 避免负数：System.exit(-1) 在 Linux 实际返回 255，不是你预期的“错误1”
- 避开 126、127（Shell 预留）和 128+（对应信号，如 130 = Ctrl+C），业务逻辑建议只用 1–125
- 大于 255 的值会取模，System.exit(300) 等价于 44，可能掩盖真实问题
不同异常要配不同退出码，不能全用 1
用固定值（比如所有错误都 System.exit(1)）等于没提供信息。应按错误类型分层定义：
- 参数解析失败 → System.exit(2)
- 配置文件读取失败 → System.exit(3)
- 网络连接超时 → System.exit(4)
- 数据库不可达 → System.exit(5)
- 许可证校验失败 → System.exit(6)
推荐在代码里建常量类统一管理，比如：public static final int CONFIG_ERROR = 3;，并在项目文档中写明每项含义。
立即学习“Java免费学习笔记（深入）”；
异常发生时，退出码得在清理之后再设
System.exit() 一执行，finally、try-with-resources、return 后续逻辑全跳过。所以不能靠“最后统一 exit”，而要前置处理：
- 先 close 文件流、flush 日志缓冲区、释放临时资源
- 再调用 System.exit(非零码)，确保数据不丢失、状态可追溯
- 若清理逻辑复杂或含阻塞 IO，优先改用自然退出（return 主方法末尾），让 JVM 正常走完 finally 和 shutdown hook
Web 或框架环境里，别直接调 System.exit
在 Spring Boot、Tomcat 等容器中调用它，等于绕过整个生命周期管理：
- 连接池不会关闭，健康检查会失联，优雅停机失效
- 正确做法是用 SpringApplication.exit(ctx, code)，它先触发 Bean 销毁、事件发布、资源回收，再调 System.exit()
- 如果只是想终止某个请求或任务，该抛异常、该设标志位、该调 stop()，而不是杀进程
