runtimeexception 与断言角色不同：前者是可捕获的运行时异常，用于处理预期内的错误；后者是调试用的逻辑哨兵，抛出 assertionerror 表示不可恢复状态，不可被 catch，且须禁用生产环境。
RuntimeException 和断言（assert）都指向程序内部逻辑的可靠性，但角色截然不同：前者是运行时可能发生的、未被强制捕获的异常，反映的是设计或环境导致的意外行为；后者是开发者主动插入的“逻辑哨兵”，只在调试阶段起效，专用于暴露那些本不该出现的状态。
断言不是 RuntimeException 的替代品
断言失败抛出的是 AssertionError（继承自 Error），而 RuntimeException 是 Exception 的子类。两者根本不在同一处理层级：
- AssertionError 表示程序已进入不可恢复的错误状态，比如“这个变量在此处绝不可能为 null”，它不应当被 try-catch 捕获，也不该试图“恢复”；
- RuntimeException（如 NullPointerException、IllegalArgumentException）代表可预期的运行时问题，业务代码中常需校验并提前拦截，或由上层统一兜底；
- 混淆二者会导致错误的设计决策——用 assert 替代参数校验，会让用户输入非法时直接崩溃，而非返回友好提示。
断言真正补充的是“契约缺失”的盲区
很多 RuntimeException 的根源，其实是方法间缺乏明确约定。断言在这里起到文档化 + 即时验证的双重作用：
- 在私有方法入口处断言前提条件（如
assert list != null && !list.isEmpty()），相当于给内部调用链加一道“逻辑保险”； - 在方法结尾断言后置条件（如
assert result > 0 : "计算结果必须为正数"），确保算法逻辑没被意外绕过或篡改； - 在循环前后断言不变式（如
assert total == sum(elements)），能快速定位迭代逻辑中的隐蔽偏差。
启用与禁用必须清晰分离
断言的价值依赖于可控的开关机制，否则容易在生产环境引发误判或性能错觉：
- 开发测试阶段务必开启：启动参数加
-ea，必要时限定包名（如-ea:com.example.service）； - 生产环境默认关闭，无需额外参数——JVM 直接跳过所有 assert 语句，零开销；
- 严禁在断言中执行有副作用的操作（如
assert (i++ > 0)或修改状态），否则关闭断言后逻辑行为会悄然改变。
和日志、单元测试形成三层防线
断言不是孤立工具，它和日志记录、单元测试共同构成稳定性保障体系：
- 单元测试覆盖典型路径和边界 case，验证功能正确性；
- 断言嵌入关键节点，守住“绝不该发生”的底线，属于代码级契约；
- 日志记录运行时实际状态（如参数值、中间结果），用于事后归因——当断言触发失败，日志能帮你看清“为什么那个布尔表达式为 false”。
