断言适用于开发测试阶段的内部一致性检查，而非生产环境的参数校验；它不替代 `objects.requirenonnull` 等防御性检查，因其可被关闭，仅用于低成本、高价值的逻辑自检。
在 Java 中，assert 语句常被误解为一种通用的参数验证机制——尤其在阅读《Effective Java》第 49 条时，初学者容易困惑：既然私有方法（private）只被本类调用，为何还要用可能被关闭的 assert，而不统一使用更可靠的 Objects.requireNonNull() 或显式 if 检查？
关键在于厘清 “验证”（validation）的目的与阶段：
✅ 断言的正确定位：开发期的轻量级契约自检
assert 的核心价值不是“防止错误发生”，而是在开发和测试阶段主动暴露设计缺陷或逻辑矛盾。它适用于以下典型场景：
- 验证私有方法执行前后不变量（invariant）是否成立
- 确保算法中间状态符合预期（如：排序后数组应满足 arr[i] <= arr[i+1]）
- 检查内部缓存、状态机转换等隐含假设
这类检查通常成本可控、语义清晰、且不应存在于生产环境。例如：
立即学习“Java免费学习笔记（深入）”；
private void mergeSort(int[] arr, int left, int right) {
if (left >= right) return;
int mid = left + (right - left) / 2;
mergeSort(arr, left, mid);
mergeSort(arr, mid + 1, right);
merge(arr, left, mid, right);
// ✅ 合理用法：仅在测试时验证排序结果正确性
assert isSorted(arr, left, right) : "Merge sort failed: subarray not sorted";
}⚠️ 注意：isSorted() 若为 O(n) 实现，在大型数组上启用断言会导致性能显著下降——这正是断言不应开启于生产环境的根本原因。
❌ 断言的误用：替代防御性编程
对方法参数（即使是私有方法）做空值或范围检查，不属于断言的职责范畴：
// ❌ 错误示范：用 assert 替代必要校验
private void processConfig(Map<String, Object> config) {
assert config != null : "config must not be null"; // 危险！若禁用断言，后续 NPE 难以定位
// ... 后续大量 config.get(...) 调用
}一旦 JVM 启动时未加 -ea（enable assertions），该检查彻底消失，错误将延迟到深层调用才抛出 NullPointerException，极大增加调试成本。此时应使用：
// ✅ 正确做法：始终生效的防御性检查
private void processConfig(Map<String, Object> config) {
Objects.requireNonNull(config, "config must not be null");
// 或更明确的业务校验
if (config.isEmpty()) {
throw new IllegalArgumentException("config cannot be empty");
}
}? 核心原则：按检查目的而非访问修饰符选择工具
正如《Effective Java》所强调：是否使用 assert，与方法是 public 还是 private 无关，而取决于该检查的语义角色：
| 检查类型 | 推荐方式 | 是否应在生产运行 | 典型场景 |
|---|---|---|---|
| 外部输入校验（用户/网络/API） | 显式 if + throw | ✅ 必须 | public void save(User u) |
| 内部参数防御性校验 | Objects.requireNonNull 等 | ✅ 必须 | private void init(List<?> data) |
| 内部逻辑一致性断言 | assert | ❌ 禁止（生产） | “循环后计数器应等于处理项数” |
? 补充建议：现代实践中的替代方案
许多团队已逐步减少 assert 使用，转而采用更可维护的方式实现同等目标：
- 单元测试覆盖：用 JUnit 断言替代代码内 assert，保障逻辑正确性且不干扰运行时
- 静态分析工具：如 SpotBugs、ErrorProne 可在编译期捕获空指针、不变量破坏等问题
- 契约式注解：配合 Lombok @NonNull 或 Checker Framework 实现编译期验证
? 总结：assert 不是“弱化的校验”，而是“专用的开发期探测器”。它存在的意义，是让程序员在编码阶段就敢于表达“这里绝不可能发生……”，并借助测试快速击穿假设——而不是在生产环境中承担本不该由它承担的可靠性责任。
