Java断言仅用于开发调试阶段内部状态校验，不可替代业务参数校验；默认关闭，需-ea启用，失败抛AssertionError（属Error），不应捕获，而应使用IllegalArgumentException等标准异常进行强制、可监控的运行时校验。
Java 中断言（assert）主要用于开发和测试阶段的调试，**不适合在业务代码中用于参数校验并抛出异常**。它默认是关闭的，生产环境通常不启用，无法保证校验逻辑生效，也不符合 Java 异常处理的最佳实践。
断言不是参数校验的正确工具
断言语句（assert condition : message;）在 JVM 默认配置下是禁用的，需显式加 -ea（enable assertions）参数才生效。一旦未开启，所有断言被忽略，业务参数非法时不会拦截，极易引发后续空指针、数组越界等隐蔽错误。
- 断言抛出的是
AssertionError（继承自Error），属于系统错误范畴，不应由业务层捕获或处理 - 标准异常处理机制（如
IllegalArgumentException、NullPointerException）才是业务校验的规范方式 - IDE 和静态分析工具（如 IntelliJ、SonarQube）会警告“不要用 assert 做输入校验”
业务代码中推荐的参数校验方式
使用明确、可捕获、语义清晰的运行时异常，并配合工具类或注解提升可读性与一致性。
-
手动抛出标准异常：例如
if (id == null) throw new IllegalArgumentException("id 不能为空"); -
使用 Apache Commons Lang 或 Guava 工具类：
Objects.requireNonNull(id, "id 不能为空")或Validate.notNull(id, "id 不能为空") -
结合 JSR-303/Bean Validation 注解（如
@NotNull、@Min）+Validator.validate()，适合 DTO 层校验 - Spring 的 @Valid / @Validated：在 Controller 方法参数上自动触发校验，异常由全局异常处理器统一响应
什么时候可以用 assert？
仅限于内部不变量检查、算法关键路径的逻辑自检、单元测试中的预期断言等**非业务路径、纯开发辅助场景**。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 例如：二分查找中某次迭代后 left ≤ right 应始终成立
- 例如：私有方法执行前，某个临时计算结果不应为负数（且该条件理论上绝不可能违反）
- 注意：这类断言不替代单元测试，也不承担防御性编程职责
一个对比示例
❌ 错误用法（断言用于业务参数检查）：
public void updateUser(Long id, String name) {
assert id != null : "id 不能为空"; // 生产环境失效！
assert name != null && !name.trim().isEmpty() : "name 不能为空";
// ... 业务逻辑
}
✅ 正确做法（显式抛出业务异常）：
public void updateUser(Long id, String name) {
if (id == null) {
throw new IllegalArgumentException("id 不能为空");
}
if (name == null || name.trim().isEmpty()) {
throw new IllegalArgumentException("name 不能为空");
}
// 或使用 Objects.requireNonNull(id, "id 不能为空");
// ... 业务逻辑
}
不复杂但容易忽略：参数校验的目标是让错误尽早暴露、信息明确、可监控可追溯。断言做不到这点，而标准异常机制天然支持日志记录、全局兜底、API 统一错误码设计。
