java断言默认关闭，需用-ea参数启用；仅用于开发阶段内部逻辑检查，不可替代异常处理，生产环境必须禁用，android等平台可能完全无效。
Java断言默认是关闭的，不加参数根本不会执行
Java 的 assert 语句在编译后仍存在字节码里，但运行时默认被 JVM 忽略。不显式开启，哪怕写成 assert false; 也不会抛异常、不会中断程序——它就像没写一样。
开启方式只有两个 JVM 参数：启动时加 -ea（enable assertions）或 -enableassertions。例如：java -ea MyApp。不加就等于没写。
-
-ea全局开启，包括所有类和包 -
-ea:com.example...只对指定包/类开启，更安全 -
-da（disable assertions）可用来局部关闭，比如跳过某个第三方库 - IDE 运行配置里也要手动加参数，不是写了 assert 就自动生效
assert 只能用于开发阶段的内部逻辑检查
它的设计定位非常明确：检测程序员自己写的“绝不该发生”的条件，比如私有方法入参校验、循环不变量、算法中间状态。它不是替代 if + throw IllegalArgumentException 的通用校验手段。
典型误用场景：
立即学习“Java免费学习笔记（深入）”；
- 检查用户输入、文件是否存在、网络响应——这些是外部可变因素，必须用显式异常处理
- 放在 public 方法入口做参数校验——生产环境断言关闭后，校验直接消失，可能引发后续空指针或越界
- 在 assert 中调用有副作用的方法，比如
assert logAndReturnFalse();——断言关闭时该方法不执行，逻辑错乱
生产环境禁用 assert 不是建议，是强制要求
因为断言可能被关闭，任何依赖它来保证正确性的代码，在生产中都会失效。更危险的是：有人会把本该抛 IllegalArgumentException 的地方写成 assert，测试时一切正常，上线后问题爆发却无报错。
还有几个现实约束：
- Android 平台默认完全忽略 assert（即使加
-ea也无效），靠它做校验等于白写 - 某些容器或云平台启动 JVM 时不传
-ea，且不允许修改启动参数 - 断言失败抛的是
AssertionError，它继承自Error而非Exception，常规catch (Exception e)捕不到，日志系统也可能漏掉
替代方案比死守 assert 更可靠
如果真需要轻量级校验，用现成的工具类比手写 assert 更稳妥。比如 Guava 的 Preconditions 或 Spring 的 Assert 工具类：
import com.google.common.base.Preconditions; // 替代 assert x != null; Preconditions.checkNotNull(x, "x must not be null");
它们在所有环境下都生效，错误信息清晰，还能配合 IDE 提示。而 assert 唯一优势是“编译期保留、运行期可开关”，但这点恰恰让它在关键路径上不可信。
真正难处理的，是那些夹在中间的“半调试”逻辑：比如某段计算结果理论上应为正数，你想快速验证但又不敢删。这时候宁可用临时日志 + 条件断点，也不要依赖 assert——毕竟，看不见的断言，比没写的还危险。
