Java断言默认关闭，需用-ea参数启用；assert只在开启时执行，双参数形式的第二参数仅失败时求值；不可用于用户输入或公共API校验，仅适用于调试内部逻辑错误。
Java断言默认是关闭的，不加参数运行根本不会执行assert
很多人写完assert x > 0;发现程序明明不满足条件却没抛异常，第一反应是“断言失效了”——其实只是 JVM 默认禁用。Java 断言必须显式开启，否则所有assert语句被编译器忽略（字节码里直接跳过），连判断逻辑都不会跑。
开启方式很简单：启动时加 JVM 参数 -ea（enable assertions）。比如：
java -ea MyApplication
常见错误现象：
- IDE 运行时没配置 VM options，断言始终静默
- 只对某包启用却写错路径，如
-ea:com.example.*漏了末尾*，实际不生效 - 误以为
javac -source 1.4之类能控制断言开关——不行，那是编译语法兼容性，和运行时无关
assert语句的两种写法与触发条件差异
Java 支持单参数和双参数assert，后者在失败时提供更明确的调试信息，但很多人忽略第二参数的求值时机——它**只在断言失败时才计算**。
立即学习“Java免费学习笔记（深入）”；
例如：
assert list != null : "list is null, size=" + list.size();
如果list为null，这行会抛NullPointerException（因为list.size()先执行了），而不是预期的AssertionError。正确做法是确保第二参数表达式本身不带副作用或空指针风险。
使用场景建议：
- 单参数
assert condition;：适合快速检查内部不变量，如循环不变式、私有方法入参校验 - 双参数
assert condition : detailMsg;：推荐用于调试阶段定位问题，detailMsg应是纯计算、无副作用的字符串拼接或常量 - 永远不要用
assert替代if (x == null) throw new IllegalArgumentException();——断言可能被关，业务校验不能依赖它
IDEA/Eclipse 中开启断言容易漏掉的两个地方
光在代码里写assert不够，IDE 的运行配置往往默认不传-ea，而且不同模块可能需要单独配。
IntelliJ IDEA：
- Run → Edit Configurations → 找到对应 Application 配置 → 在
VM options框里填-ea - 如果项目含多个模块，且只想对测试模块开断言，用
-ea:com.example.test...限定包名，避免影响主流程 - 别只改「Templates」里的默认配置——已存在的运行配置不会自动继承，得一个个点进去手动加
Eclipse：
- 右键类 → Run As → Run Configurations → Arguments 标签页 →
VM arguments输入-ea - 注意：Eclipse 的「Default VM Arguments」在 Preferences 里，但只影响新创建的配置，老配置仍需单独处理
断言不适合用在哪些地方？
断言不是日志，也不是防御性编程工具。它的设计初衷是捕获“绝不该发生”的内部逻辑错误，而非处理可预期的外部异常。
典型误用：
- 检查用户输入：
assert name != null;—— 输入为空很常见，该用Objects.requireNonNull或显式 if 判断 - 代替 try-catch：
assert file.exists() : "config missing";—— 文件可能被删、权限不足，这是运行时环境问题，不是代码逻辑 bug - 在 public API 方法里用断言校验参数 —— 调用方无法控制你的 JVM 参数，一旦断言关闭，校验就消失了
- 在性能敏感路径反复调用复杂断言表达式 —— 即使关闭了，编译器虽会剔除，但开发阶段开着时，表达式求值本身就有开销
真正该用断言的地方很窄：私有方法结束前验证中间状态、算法循环体内的不变式、单元测试中辅助定位哪一步出错。它是个调试开关，不是生产环境的护栏。
