断言不能替代异常处理，它仅用于开发阶段验证内部逻辑不变量，失败表明代码存在bug；异常则用于处理运行时不确定性，必须始终生效并妥善应对。
不能用断言替代异常处理。
断言（assert）和异常（Exception/Error）在 Java 中职责完全不同，强行替代会导致逻辑错误、生产事故或调试失效。
断言不是异常的简化版，而是开发阶段的“逻辑自检哨兵”
它只用于验证“理论上绝不可能为 false”的内部状态，比如算法中间结果、私有方法传入的缓冲区有效性、循环不变量等。一旦失败，说明代码本身存在 bug，应立即终止、修复，而不是继续运行或恢复。
异常才是处理运行时不确定性的正确机制
用户输入非法、文件不存在、网络超时、数据库连接失败……这些都属于外部可变因素，必须用 if 校验 + 显式抛出业务异常（如 IllegalArgumentException），或用 try-catch 捕获并妥善处理。
哪些情况看似能“用断言代替”，实则危险？
-
✅ 正确：内部工具方法约定参数非 null，且调用方完全可控
private void processInternal(Buffer buffer) { assert buffer != null : "buffer must be non-null in internal call"; // 后续直接使用 buffer } -
❌ 错误：把 Web 层接收的用户 ID 用 assert 校验
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java下载在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
// 危险！生产环境断言默认关闭，ID 为 null 会静默通过，后续 NPE assert id != null : "id required";
✅ 应改为：
if (id == null) { throw new IllegalArgumentException("id cannot be null"); } -
❌ 错误：用 assert 替代空指针防护，掩盖真实问题
assert obj.getName() != null; // 若 getName() 抛 NPE，assert 还没执行就崩了
✅ 应先判空，再操作：
if (obj == null || obj.getName() == null) { throw new IllegalStateException("obj or name is null"); }
断言与异常的核心区别
| 维度 | 断言（assert） |
异常（throw new XxxException()） |
|---|---|---|
| 目的 | 发现开发者自己的逻辑错误 | 处理运行时不确定性（输入、IO、并发等） |
| 启用状态 | 默认关闭，需 -ea 启动参数 |
始终生效，无需额外配置 |
| 失败后果 | 抛 AssertionError（继承 Error），无法也不该捕获 |
抛 Exception 或其子类，可捕获、重试、降级、记录 |
| 生产环境 | 必须关闭，否则可能意外中断服务 | 必须存在，是健壮性的基础 |
| 表达意图 | “这绝不可能发生，发生了就是代码写错了” | “这事可能发生，我已准备应对方案” |
什么时候可以共存？——分层校验，各司其职
public void transferMoney(Account from, Account to, BigDecimal amount) {
// 第一层：业务规则校验（面向调用方，始终生效）
if (from == null || to == null) {
throw new IllegalArgumentException("account cannot be null");
}
if (amount == null || amount.signum() <= 0) {
throw new IllegalArgumentException("amount must be positive");
}
// 第二层：内部契约校验（仅开发/测试期兜底，防逻辑漏洞）
assert from.getBalance().compareTo(amount) >= 0 :
"insufficient balance: " + from.getBalance() + " < " + amount;
// 执行转账（可能仍需 try-catch 处理 DB 异常等）
from.decrease(amount);
to.increase(amount);
}这里 assert 不是替代异常，而是补充：它不负责拦截用户错误，而是盯住“扣款前余额检查通过，但扣款时 still 余额不足”这类反常状态——那说明 decrease 方法内部逻辑有缺陷。
不复杂但容易忽略。
