assert 是java开发阶段辅助发现逻辑错误的轻量级断言机制，仅用于验证“理论上绝不该发生”的内部状态，如算法中间结果、私有方法入参契约、循环不变式，且默认禁用，需通过-ea参数启用。
assert 是什么，什么时候该用
Java 的 assert 不是生产环境的校验工具，而是开发阶段辅助发现逻辑错误的轻量级断言机制。它只在启用断言时生效（默认关闭），一旦失败直接抛出 AssertionError，不捕获、不恢复——这意味着你不能靠它来处理用户输入或外部数据异常。
适用场景很窄：仅用于验证“理论上绝不该发生”的内部状态，比如算法中间结果、私有方法入参契约、循环不变式。例如：assert list.size() >= 0; 或 assert node != null : "parent must not be null";
- 不要在 public 方法入口用
assert检查参数——该用Objects.requireNonNull()或自定义异常 - 不要依赖
assert做安全控制（如权限检查），JVM 启动时没加-ea就完全跳过 - 断言表达式里别有副作用，比如
assert (x = x + 1) > 0;—— 开发时可能跑通，上线就逻辑错乱
怎么开启和关闭 assert
Java 默认禁用所有断言，必须显式启用。核心就两条 JVM 参数：
- 全局启用：
-ea（即-enableassertions） - 只对某个包启用：
-ea:com.example.util...（注意末尾的...表示子包） - 禁用某类断言：
-da:com.example.service...（-da=-disableassertions）
IDE 运行配置里容易漏掉这个——IntelliJ 默认不带 -ea，Eclipse 也得手动加进 Run Configuration 的 VM options。Maven Surefire 插件测试时若想启用，得配 <argline>-ea</argline>
立即学习“Java免费学习笔记（深入）”；
常见错误现象：assert false; 语句静默通过，没有任何报错 → 八成是忘了加 -ea 启动参数。
assert 和 if + throw 的关键区别
表面上都是“条件不满足就中断”，但语义和生命周期完全不同：
-
assert是开发期信号，代表“这里出问题说明代码逻辑有缺陷”，不是运行时异常流的一部分；if (!valid) throw new IllegalArgumentException();是明确的契约声明，生产环境也必须执行 -
assert的消息只能是字符串字面量或简单表达式，不能调用方法（否则可能因断言关闭而跳过副作用）；而throw可以构造任意复杂对象 - 编译器不会为
assert生成字节码分支逻辑（除非启用），但if总会生成；所以压测时如果误留大量 assert，又没关掉，会有轻微性能开销
一个典型误用：assert file.exists() : readFile(file); —— readFile() 在断言关闭时根本不会执行，但开发者本意可能是想记录日志，这就错了。
为什么线上通常禁用 assert
不是因为“不重要”，而是因为它和生产环境的目标冲突：
- 断言失败抛
AssertionError，属于Error体系，按规范不应被捕获或重试，服务直接崩；而线上需要的是可观察、可降级、可恢复的失败 - 断言不提供错误上下文（比如 HTTP 状态码、trace ID、用户 ID），运维无法定位问题源头
- 某些 JDK 版本在高并发下启用断言可能触发 JIT 优化退化（虽少见，但在金融/高频场景曾有案例）
真正该做的是：把关键断言点转成带监控埋点的显式校验，比如 if (x 。断言只留在单元测试或本地调试时快速暴露假设破灭的位置。
最容易被忽略的一点：CI 流水线里的测试任务如果没配 -ea，等于白写了 assert——它既没起作用，也没人知道它失效了。
