assert工具类配合illegalargumentexception用于方法入口集中参数校验，统一入口、提升可读性；仅校验参数本身合法性，不替代业务规则校验。
IllegalArgumentException 和 Assert 工具类配合使用，核心目标是让参数校验更简洁、语义更清晰、错误信息更精准——不是为了“多一层封装”，而是统一校验入口、减少重复判断、提升协作可读性。
校验时机：方法入口处集中断言
所有业务逻辑执行前，用 Assert 一次性完成参数合法性检查。避免在方法体中零散出现 if-throw，也避免把校验逻辑混进业务分支里。
- 构造方法、public 方法必须校验；protected/package-private 方法按需校验（尤其被跨模块调用时）
- Assert 调用应紧贴方法第一行，例如：
Assert.notNull(user, "用户对象不能为空");
Assert.isTrue(user.getAge() >= 0 && user.getAge() - 不推荐在循环内或条件分支中反复调用 Assert —— 它属于前置守门员，不是运行时监控器
异常语义：用标准异常，不自定义包装
Assert 工具类内部直接抛出 IllegalArgumentException（或 NullPointerException、IllegalStateException 等），不包装成自定义异常类型。保持语义透明，符合 JDK 规范和团队共识。
- 消息格式统一为「字段名 + 违反规则 + 实际值（可选）」，例如：
"超时时间不能为负数: -500"、
"文件路径不能为空字符串" - 避免模糊描述如“参数错误”“非法输入”，也不拼接堆栈或上下文ID（那是日志的事）
- 若需携带业务码（如 HTTP 400 错误码），应在全局异常处理器中统一映射，而非在 Assert 抛出时硬编码
工具选择：优先用成熟断言库，不手写重复逻辑
直接使用 Guava 的 Preconditions 或 Spring 的 Assert，比自己维护 AssertUtils 更可靠、更易升级、文档更全。
- Guava 示例：
Preconditions.checkNotNull(name, "用户名不可为空");
Preconditions.checkArgument(count > 0, "请求数量必须大于0，当前值：%s", count); - Spring 示例：
Assert.notNull(file, "上传文件对象为空");
Assert.state(!task.isRunning(), "任务正在运行中，不可重复触发"); - 自研工具类仅在有强定制需求时考虑（如集成统一错误码体系），但需确保其行为与标准库一致，不破坏语义直觉
边界注意：不替代业务规则校验
Assert 只负责“参数本身是否合法”，不承担“参数组合是否合理”或“外部状态是否满足”的职责。后者属于业务校验，应放在 service 层或 domain 层处理。
- ✅ 合适：
Assert.notNull(orderId, "订单ID不能为空")、Assert.isTrue(amount > 0, "支付金额必须为正") - ❌ 不合适：
Assert.isTrue(user.hasPermission("DELETE"), "权限不足")（权限是运行时状态，非入参固有属性） - ❌ 不合适：
Assert.isTrue(stockService.hasStock(itemId), "库存不足")（依赖外部服务，不应在参数层校验）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
