断言不是环境切换开关，AssertionError用于暴露严重逻辑缺陷而非业务分支，-ea仅开启调试验证，不可用于生产与测试的差异化异常逻辑。
不能也不应该用 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 是它的电源开关，不是环境路由表。想靠它做差异化逻辑，就像用体温计控制空调温度——工具错配，结果必然失控。
