Java 的 assert 默认是关闭的，不加参数就白写
Java 编译器认得 assert 语句，但 JVM 默认禁用断言机制——哪怕你写了 assert x > 0;，运行时也完全不检查。这不是 bug，是设计如此：断言只用于开发/测试阶段，生产环境默认关掉，避免性能开销和副作用。
要让它生效，必须显式开启：
- 运行时加
-ea（-enableassertions）参数：java -ea MyApp - 只对某个包开启：
java -ea:com.example... MyApp - 禁用某类断言（比如第三方库）：
-da:org.apache...
IDE 运行配置里也得手动加 VM options，光改代码没用。常见坑是本地 IDE 跑通了，扔进 CI 或脚本里就失效——因为没传 -ea。
assert 后面只能跟布尔表达式，别塞赋值或方法调用
语法上 assert 接收一个布尔条件，可选一个冒号加失败时的提示表达式。但它不是 if，也不参与正常流程控制。
立即学习“Java免费学习笔记（深入）”；
这些写法会出问题：
-
assert list.add(item);——add()返回boolean，看似合法，但断言关闭时这行直接被跳过，item就没加进去，逻辑错乱 -
assert x = 5;—— 赋值表达式在 Java 里不是布尔值，编译直接报错incompatible types: int cannot be converted to boolean -
assert isValid() && log("checked");——log()在断言关闭时不执行，但你可能误以为它总被调用
正确姿势：断言只做“校验”，不带副作用。想记录日志、修改状态，请用 if (!condition) { ... } 显式处理。
断言失败抛 AssertionError，不能用 try-catch 捕获来兜底
AssertionError 是 Error 的子类，不是 Exception。JVM 设计初衷就是“断言失败=程序逻辑崩了，不该恢复”，所以它不在常规异常处理路径上。
这段代码不会按你想的走：
try {
assert false;
} catch (AssertionError e) {
System.out.println("caught!"); // 这行永远不会执行
}
原因：
- 即使开了
-ea，AssertionError仍属于 uncheckedError，编译器不强制捕获 - 真去 catch 它，等于把“开发期发现的严重逻辑错误”当成可恢复的业务异常，掩盖问题本质
- 线上开了断言还 try-catch，反而让崩溃更隐蔽——比如本该立刻暴露的空指针，在 catch 里默默吞掉
真需要容错，就别用 assert，改用明确的 Objects.requireNonNull() 或自定义校验逻辑。
替代方案比硬扛 assert 更可靠：单元测试 + Objects.requireNonNull
断言的适用场景其实很窄：仅限于“这个条件在开发阶段必须为真，否则说明代码写错了”，比如私有方法入参校验、循环不变量、算法中间态。
但实际项目中，更多校验需求更适合交给其他机制：
- 构造函数/公有 API 入参校验 → 用
Objects.requireNonNull()或Preconditions.checkNotNull()，运行期必检，不依赖 JVM 参数 - 业务规则校验（如“余额不能为负”）→ 抛
IllegalArgumentException，由上层决定如何响应 - 逻辑正确性保障 → 写 JUnit 测试，覆盖边界和异常路径，比断言更稳定、可重复、易集成
断言容易被遗忘开启、无法在 CI 自动触发、IDE 提示弱、团队协作时理解成本高。真正关键的校验点，别指望靠它兜底。
最常被忽略的一点：断言没有堆栈上下文增强能力。比如 assert size == expected : "size mismatch at step " + step;，一旦失败，你得靠那个字符串猜位置；而单元测试失败时，IDE 直接定位到断言行，还能对比实际/期望值。
