java Assert断言为什么推荐用

在 Java 里，assert 断言之所以被“推荐用”，主要是因为它能在开发和测试阶段快速暴露程序内部错误，而且使用成本极低。但要注意：它并不是用来做业务校验或用户输入检查的，而是用于“程序内部不应发生的情况”。

下面分层说明为什么推荐用，以及什么时候该用、不该用。

一、Assert 的本质

assert condition;
// 或
assert condition : "错误信息";

• 如果 condition 为 false
  • 抛出 AssertionError
• 默认是关闭的，需要 JVM 参数开启：

  java -ea Main
  

二、为什么推荐用（核心价值）

✅ 1. 快速发现“不可能发生”的逻辑错误

断言表达的是：

“这里在正确程序中一定为真”

例如：

int age = calculateAge();
assert age >= 0 : "年龄不可能为负";

一旦为负，立刻报错，而不是带着错误状态继续运行。

✅ 2. 文档化“前置/后置条件”

断言相当于可执行的设计说明。

public int pop() {
    assert !stack.isEmpty() : "栈不应为空";
    ...
}

比注释更可靠：

• 注释会被忽略
• 断言会在运行中被验证

✅ 3. 不影响生产性能（可一键关闭）

• 开发 / 测试：开启 -ea
• 生产：关闭（默认）

✅ 没有运行时成本
❌ 不会拖慢系统

✅ 4. 比异常更“轻”

• IllegalArgumentException：给调用者看的
• assert：给开发者看的

断言失败 = 程序有 bug
异常 = 外部输入或状态不合法

三、什么时候“不推荐”用 assert（很重要）

❌ 1. 不要用 assert 校验外部输入

// 错误示范
assert username != null;

✅ 正确做法：

if (username == null) {
    throw new IllegalArgumentException("用户名不能为空");
}

原因：

• 生产环境断言可能关闭
• 用户输入错误不是“程序 bug”

❌ 2. 不要用 assert 做业务控制

assert balance >= amount; // ❌

业务规则必须用异常或校验框架。

❌ 3. 不要依赖断言来保证安全

断言可以被关闭，不能用于安全校验。

四、推荐的最佳实践

✅ 适合用 assert 的地方

• 私有方法内部
• 不变量（invariant）
• 循环不变量
• 算法中间状态
• 单元测试和调试阶段

✅ 典型模式

// 前置条件
assert param != null;

// 后置条件
assert result > 0;

// 不变量
assert size >= 0;

五、一句话总结

Java 断言推荐用，是因为它用极低成本，把“程序员的假设”变成“可验证的事实”。

但记住一句铁律：

assert 是对自己说的，不是对用户说的。

如果你愿意，我也可以对比 assert vs JUnit Assertions vs Spring Assert，或者给你一个真实业务中的使用示例。