java 的 assert 语句适用于开发与测试阶段的内部一致性检查，而非生产环境的参数校验；它不可替代 `objects.requirenonnull` 等运行时防御性检查，因其默认关闭、不可控且不具契约保障。
在 Java 开发中，assert 语句常被误解为一种通用的参数验证工具，尤其在阅读《Effective Java》第 49 条时，初学者易将“私有方法中可用 assert”等同于“适合用 assert 做参数校验”。实际上，这背后涉及三类不同性质的检查，需严格区分：
✅ 场景一：开发/测试期的内部一致性断言（assert 的正确定位）
适用于模块内部不变量（invariant）验证，例如：
- 某算法执行后，链表长度应等于节点计数器值；
- 多线程临界区退出前，锁状态必须为已释放；
- 递归函数返回前，中间结果满足数学约束（如 sum == leftSum + rightSum）。
这类检查往往开销较大，可能影响性能或改变时间复杂度。因此，仅应在开发和单元测试阶段启用（通过 -ea JVM 参数），绝不可用于生产环境：
private void balanceTree(Node root) {
// 仅用于调试：验证平衡操作后树高差 ≤ 1
assert Math.abs(height(root.left) - height(root.right)) <= 1
: "Tree imbalance detected after balancing";
// ... 实际平衡逻辑
}⚠️ 注意：若未启用断言（默认关闭），该检查完全不执行——这正是设计本意，而非缺陷。
❌ 场景二：外部输入校验（绝对禁用 assert）
用户输入、API 请求参数、配置文件读取等外部数据，必须在生产环境持续校验。assert 因可被全局关闭，完全不适用：
- 数据库写入前未校验空值 → 插入 NULL 导致业务逻辑异常；
- 未校验 JSON 字段类型 → ClassCastException 崩溃；
- 忽略权限参数校验 → 安全漏洞（如越权访问）。
✅ 正确做法：使用 Objects.requireNonNull()、IllegalArgumentException 或 Jakarta Validation 等运行时强制检查：
private void processOrder(Order order) {
Objects.requireNonNull(order, "order must not be null");
if (order.getItems().isEmpty()) {
throw new IllegalArgumentException("order must contain at least one item");
}
// ... 业务逻辑
}⚖️ 场景三：内部 API 的防御性校验（推荐用显式检查，非 assert）
即使方法是 private，若其被同一模块内多个路径调用（如工具类、模板方法钩子），参数错误往往反映上游逻辑缺陷。此时关闭校验会导致错误延迟暴露、堆栈信息失真、调试成本陡增。
因此，方法可见性（public/private）不是决定因素，校验目的才是关键。private 方法中仍应优先使用显式校验：
// ✅ 推荐：明确、可靠、生产环境生效
private void updateCache(String key, Object value) {
if (key == null || key.trim().isEmpty()) {
throw new IllegalArgumentException("cache key cannot be null or blank");
}
cache.put(key, value);
}
// ❌ 不推荐：生产环境失效，掩盖真实问题
private void updateCache(String key, Object value) {
assert key != null && !key.trim().isEmpty() : "key validation failed";
cache.put(key, value);
}? 总结建议
- 永远不要用 assert 校验外部输入或核心业务契约；
- assert 仅用于低成本、高价值的开发期逻辑自检（如算法不变量、状态机转换断言）；
- 私有方法 ≠ 可放松校验：若参数错误源于本模块 Bug，显式抛异常比断言更利于快速定位；
- 团队规范优于个人习惯：许多成熟项目（如 Spring、Guava）完全避免 assert，改用静态分析（SpotBugs）、单元测试覆盖率和契约式编程保障质量。
最终，assert 是调试辅助工具，不是可靠性保障机制——真正的健壮性
