java Assert断言有哪些常见坑

在 Java 中使用 assert 关键字（断言）时，有很多容易被忽视的“坑”，不少开发者在面试或实际排查问题时都踩过。下面按常见误区 → 风险 → 正确做法来说明。

1️⃣ 断言默认是关闭的（最常见坑）

问题

Java 的 assert 默认不启用。

assert x > 0 : "x must be positive";

如果直接运行：

java Main

这行断言永远不会执行。

正确做法

必须显式开启：

java -ea Main
# 或
java -enableassertions Main

❗ 生产环境 JVM 往往没开 -ea，断言形同虚设。

2️⃣ 用断言做参数校验（严重误用）

错误示例

public void setAge(int age) {
    assert age > 0;
    this.age = age;
}

风险

• 断言关闭时，非法参数直接通过
• 可能导致后续逻辑崩溃、数据错误

正确做法

用异常，而不是断言：

if (age <= 0) {
    throw new IllegalArgumentException("age must > 0");
}

✅ 断言只用于“不可能发生的情况”

3️⃣ 断言中包含“有副作用”的代码

错误示例

assert list.remove(0) != null;

问题

• 断言关闭时，remove() 不会执行
• 程序行为不一致

正确做法

boolean removed = list.remove(0);
assert removed;

✅ 断言只做“判断”，不做“操作”

4️⃣ 用断言控制业务流程

错误示例

assert login();

问题

• 断言关闭 → 登录逻辑被跳过
• 业务逻辑直接崩坏

正确做法

业务判断必须用 if + 异常 / 返回值

5️⃣ 断言异常被“吞掉”

现象

开启断言后抛出：

java.lang.AssertionError

但很多人：

• 不捕获
• 不日志记录
• 不知道哪一行炸了

建议

• 断言信息要清晰、可读

assert user != null : "user should not be null at this point";

6️⃣ 断言不能替代单元测试

误区

“我有 assert，就不需要写测试”

事实

• 断言只在运行时生效
• 单元测试能在编译/CI 阶段发现问题

✅ 断言 ≠ 测试工具

7️⃣ 断言在 JDK 不同版本行为一致，但容易被忽略

• AssertionError 是 Error 不是 Exception
• 不应被 catch (Exception e) 捕获

try {
    assert false;
} catch (Exception e) {
    // ❌ 抓不到
}

✅ 断言正确使用场景总结

✅ 适合：

• 内部不变量
• 永不执行的代码分支
• 调试阶段假设验证

❌ 不适合：

• 参数校验
• 业务判断
• 安全控制
• 生产环境强依赖

一句话总结

Java 的 assert 是“开发期辅助工具”，不是“运行时防护机制”。

如果你愿意，我也可以对比 JUnit Assert / AssertJ / Guava Preconditions 的使用差异。