Java 中断言（assert）在私有方法中的正确用途与适用场景_技术教程

断言适用于开发测试阶段的内部一致性检查，而非生产环境的参数校验；它不替代 `objects.requirenonnull` 等防御性检查，因其可被关闭，仅用于低成本、高价值的逻辑自检。

在 Java 中，assert 语句常被误解为一种通用的参数验证机制——尤其在阅读《Effective Java》第 49 条时，初学者容易困惑：既然私有方法（private）只被本类调用，为何还要用可能被关闭的 assert，而不统一使用更可靠的 Objects.requireNonNull() 或显式 if 检查？

关键在于厘清 “验证”（validation）的目的与阶段：

✅ 断言的正确定位：开发期的轻量级契约自检

assert 的核心价值不是“防止错误发生”，而是在开发和测试阶段主动暴露设计缺陷或逻辑矛盾。它适用于以下典型场景：

验证私有方法执行前后不变量（invariant）是否成立
确保算法中间状态符合预期（如：排序后数组应满足 arr[i]
检查内部缓存、状态机转换等隐含假设

这类检查通常成本可控、语义清晰、且不应存在于生产环境。例如：

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 config) {
    assert config != null : "config must not be null"; // 危险！若禁用断言，后续 NPE 难以定位
    // ... 后续大量 config.get(...) 调用
}

一旦 JVM 启动时未加 -ea（enable assertions），该检查彻底消失，错误将延迟到深层调用才抛出 NullPointerException，极大增加调试成本。此时应使用：

// ✅ 正确做法：始终生效的防御性检查
private void processConfig(Map 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	❌ 禁止（生产）	“循环后计数器应等于处理项数”