断言适用于开发测试阶段的内部一致性检查，而非生产环境的参数校验；它不可替代 `objects.requirenonnull` 等运行时防御性检查，因其默认关闭、性能敏感且语义不同。
在 Java 中，assert 语句常被误解为一种通用的参数验证工具，尤其在阅读《Effective Java》第49条时，初学者易将“私有方法中可用断言”等同于“推荐用断言做输入检查”。实际上，断言的核心价值不在于验证输入合法性，而在于捕获开发阶段的逻辑错误与不变量破坏。
✅ 断言的正确使用场景：开发期内部契约检查
断言应仅用于检测本不该发生的内部状态异常，例如：
- 私有方法执行后，某个关键数据结构仍满足预期不变量（如“排序后数组首元素 ≤ 末元素”）；
- 递归算法中某轮迭代前，递归深度未超出理论上限；
- 缓存更新后，缓存命中率统计值仍在合理区间（仅测试时启用，避免影响线上吞吐）。
这类检查往往开销较大，且仅对开发者调试有意义。因此，JVM 默认禁用断言（-ea 需显式开启），正是为了确保生产环境零干扰：
private void updateCache(List- items) { // ... 更新逻辑 assert items != null : "items must not be null after load"; assert cache.size() >= expectedMinSize() : "cache underflow detected"; }
⚠️ 注意：上述断言在生产环境中完全不执行——这恰恰是设计目标，而非缺陷。
立即学习“Java免费学习笔记（深入）”；
❌ 断言的错误使用：替代运行时参数校验
无论方法是 public 还是 private，只要该检查旨在防止非法输入导致后续逻辑崩溃或数据污染，就必须使用运行时强制校验：
private void processUserInput(String input) {
// ✅ 正确：即使私有方法，也需保证 input 合法性（可能来自 public 入口传递）
Objects.requireNonNull(input, "input cannot be null");
if (input.isBlank()) {
throw new IllegalArgumentException("input must not be blank");
}
// ... 处理逻辑
}原因很明确：
- assert 可被关闭 → 生产环境跳过校验 → null 输入穿透至深层逻辑，引发 NullPointerException 或脏数据；
- Objects.requireNonNull 在所有环境生效 → 提供稳定、可预测的失败点（fail-fast）；
- 二者语义本质不同：assert 是“开发期断言程序逻辑无误”，requireNonNull 是“运行时强制契约守卫”。
? 关键结论：访问修饰符不是决策依据，校验目的才是
《Effective Java》提及“私有方法可用断言”，其隐含前提是：该私有方法仅被本类可信代码调用，且断言检查的是内部实现不变量（如算法中间状态），而非外部传入参数的合法性。一旦参数来源存在不确定性（例如由 public 方法解析后传入），即应改用运行时检查。
? 实践建议： 优先用 Objects.requireNonNull、Preconditions.checkArgument（Guava）等做输入防护； 仅在单元测试/集成测试中启用断言（-ea），用于暴露隐藏逻辑缺陷； 在 CI 流程中配置 -ea 运行部分测试，让断言成为质量门禁的一部分； 团队若倾向统一风格，可完全弃用 assert，改用 JUnit 的 assertTrue() 或自定义 @Test 辅助方法——语义更清晰，且不受 JVM 参数影响。
