不推荐用异常机制实现多层退出，因其混淆错误语义、破坏调用栈、干扰监控调试；应改用带标签的break、布尔标志位或提取方法+return等语义清晰、资源可控的方式。
异常机制不适合做退出控制
抛出 RuntimeException（比如 new RuntimeException("exit")）看似能“立刻终止”，但实际带来严重问题：
- JVM 会打印完整堆栈，日志里全是“疑似崩溃”痕迹，运维和监控系统无法区分是真实故障还是你故意退出
- 退出码固定为 1，无法表达业务含义（如“用户取消”“配置无效”“超时放弃”）
- 资源清理不可控：finally 块可能没执行完，shutdown hook 可能因状态不一致而失败
- 在 Spring、Quarkus 等框架中，异常会被统一拦截、包装、记录，甚至触发重试或健康检查告警
真正高效又清晰的多层退出方式
根据场景选一种，比“抛异常”更直接、更安全、更易维护：
-
带标签的 break：适用于纯循环逻辑，想立刻跳出指定外层循环。语法简单，语义明确，无额外开销
示例：outer: for (...) { for (...) { if (done) break outer; } } -
布尔标志位：适合嵌套深、退出条件分散、或需兼顾可读性与跨语言习惯的场景
写法：声明volatile boolean shouldExit = false;，各层循环条件加&& !shouldExit，触发时设为 true 并 break 内层 - 提取为方法 + return：当整个嵌套逻辑是一个独立任务（如查找、校验、解析），把它封装成 void 或 boolean 方法，满足条件直接 return —— 逻辑自解释，测试友好，天然支持提前退出
什么时候才考虑用异常？
仅限于极少数跨线程、跨组件、无法修改调用链的遗留场景，例如：
- 子线程检测到致命错误，必须通知主线程终止整个流程，且无法通过共享变量或队列通信
- 第三方库回调中发生不可恢复状态，而你又无法改造其 API
即便如此，也应定义专用异常（如 AbortProcessingException），并在最外层显式捕获、记录、清理后退出，而不是任由它冒泡到 JVM 默认处理器。
立即学习“Java免费学习笔记（深入）”；
不复杂但容易忽略：退出意图要清晰，手段要匹配场景。用对工具，比“快”更重要。
