Java断言（assert）仅用于开发测试阶段暴露逻辑错误，生产环境默认关闭，不参与参数校验；正确入参校验应使用Objects.requireNonNull、JSR-303注解或自定义工具类，确保始终生效、语义明确、可监控。
Optional 和断言（assert）在 Java 企业级开发中承担不同职责：Optional 用于**显式表达可能缺失的返回值**，侧重运行时安全与可读性；断言用于**开发/测试阶段快速暴露逻辑错误**，默认关闭、不参与生产校验。二者不能混用，也不应“结合”做参数校验——强行搭配反而削弱健壮性、掩盖真实问题。
为什么不能用断言校验入参
断言在生产环境默认禁用（-da），JVM 直接跳过所有 assert 语句。这意味着：
- 用户传入
null参数，断言不会执行，后续代码直接抛NullPointerException - 参数校验逻辑失效，无法保障接口契约，违反“尽早失败”原则
- 断言抛出的是
AssertionError（继承自Error），属于系统级严重错误，**禁止捕获、不应用于业务流程控制**
参数校验该用什么
企业级场景必须使用**始终生效、语义明确、可监控可追溯**的校验方式：
-
Objects.requireNonNull(param, "xxx不能为空")—— 立即抛NullPointerException或自定义异常，堆栈清晰，Spring 等框架能自动映射为 HTTP 400 错误 - JSR-303/380 注解（
@NotNull、@NotBlank、@Valid）—— 配合 Spring Validation，在 Controller 层统一拦截并返回结构化错误响应 - 自定义校验工具类（如封装
StringUtils.isBlank()+CollectionUtils.isEmpty()）—— 适用于 Service 内部对非外部输入的轻量检查
Optional 的正确出场时机
Optional 不是 null 检查替代品，而是**用于方法返回值设计**，表明“这个值可能不存在”，且调用方必须主动处理：
立即学习“Java免费学习笔记（深入）”；
- DAO 层查询单个实体：用
Optional<user> findById(Long id)</user>，比返回User+ 文档说明“可能为 null”更可靠 - 链式取值防 NPE：
userOpt.map(User::getProfile).map(Profile::getEmail).orElse("no-email@example.com") - 避免将 Optional 作为参数或字段类型 —— 违反其设计初衷，增加调用方负担
- 集合、数组、基本类型包装类等场景，优先返回空集合、默认值或原始类型，而非
Optional<list>></list>
一个典型反例与正解对比
错误写法（混用断言 + Optional）：
❌public User findUser(Long id) {
assert id != null : "id must not be null"; // 生产无效！
return Optional.ofNullable(userDao.findById(id))
.orElseThrow(() -> new UserNotFoundException("not found"));
}
正解（分层清晰、生产可用）：
✅public User findUser(@NotNull Long id) { // JSR-303 注解驱动校验
return userDao.findById(id)
.orElseThrow(() -> new UserNotFoundException("用户未找到: " + id));
}
// DAO 接口返回 Optional
public interface UserDao {
Optional<User> findById(Long id); // 明确语义：查不到就为空
} 
