使用 -ea 参数开启断言，结合 AssertionError 实现环境区分逻辑。

断言（assert）及其启用参数 -ea 是专为开发调试设计的代码逻辑验证工具，用于暴露严重内部缺陷而非实现环境差异化行为；滥用它来区分测试与生产环境的异常处理不仅会掩盖真实错误、破坏系统一致性，还违背软件分层设计原则；正确做法是通过配置驱动（如 Spring Profile）、明确异常类型（如 IllegalArgumentException）和职责分明的服务适配机制来实现环境感知逻辑，让断言回归其本质——一把精准定位问题的“手术刀”，而非被误用的环境路由开关。

不能也不应该用 AssertionError 和 -ea 实现生产与测试环境的“差异化异常逻辑”。

断言不是环境切换开关

AssertionError 是 JVM 在断言失败时抛出的 Error（继承自 java.lang.Error），代表程序存在严重逻辑缺陷，比如“本不该为 null 的对象居然为 null”。它不是设计来承载业务分支逻辑的，更不是环境配置的替代品。

• 断言默认关闭：JVM 启动时不加 -ea，所有 assert 语句被完全跳过，字节码里不执行、不求值、无任何副作用
• 断言不可恢复：AssertionError 不该被捕获，也不该用于流程控制；捕获它掩盖了真正需要修复的代码问题
• 断言无业务语义：它验证的是开发者对内部状态的假设（如循环不变式、私有方法契约），而非用户输入、外部依赖或业务规则

为什么“差异化异常逻辑”这条路走不通

试图靠 -ea 开关让同一段代码在测试环境抛 AssertionError、在生产环境静默运行，会带来三重风险：

• 逻辑漏洞被掩盖：例如 assert user != null; 在生产环境失效，后续代码触发 NullPointerException，错误位置后移、堆栈更难读
• 行为不一致且不可测：同一输入在不同环境表现不同，破坏“一次编写、随处可靠”的基本前提
• 违反分层职责：环境差异应由配置驱动（如 Spring Profile、配置中心）、由明确的异常类型表达（如 IllegalArgumentException），而非依赖一个调试工具的开关

正确的替代方案

要实现环境感知的错误处理，应使用明确、可控、可测试的机制：

• 参数校验统一用异常：公共方法入参检查必须用 if (x == null) throw new IllegalArgumentException(...)，确保无论是否启用断言都生效
• 环境差异化靠配置：用 @Profile("test") 或 spring.profiles.active=test 控制是否开启额外日志、是否启用模拟服务、是否抛出特定测试异常
• 内部逻辑验证仍可用断言，但仅限私有场景：例如在工具类私有方法开头写 assert list != null;，只在开发/单元测试时启用 -ea 辅助定位 bug，上线前确保它已无实际影响
• 需要“软失败”就用返回值或专用异常：比如测试环境调用支付接口返回模拟成功，生产环境调真实接口——这是服务适配器的责任，不是断言的事

一句话总结

断言是手术刀，用来解剖和修正代码逻辑；-ea 是它的电源开关，不是环境路由表。想靠它做差异化逻辑，就像用体温计控制空调温度——工具错配，结果必然失控。

到这里，我们也就讲完了《使用 -ea 参数开启断言，结合 AssertionError 实现环境区分逻辑。》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！