illegalargumentexception 是接口契约的显式守门人，须在方法入口立即校验参数合法性，消息需精准归因且不泄露敏感信息，null 校验优先用标准工具，不替代业务异常。
在公开 API 中，IllegalArgumentException 不是“出错了才抛”，而是契约落地的显式信号——它把接口文档里那句“age 必须为 0–150 的整数”变成运行时不可绕过的守门人。
校验位置必须紧贴方法入口
契约的有效性取决于校验是否发生在第一行可执行代码处。延迟到业务逻辑中间或计算后才校验，就等于把责任从调用方悄悄转嫁给了实现方。
- ✅ 正确：构造函数、public 方法开头立即检查
- ❌ 错误：先查数据库、再算权重、最后发现 ID 是负数才抛
- ⚠️ 风险：若后续逻辑有副作用（如发消息、写日志），异常抛出前已污染状态
消息内容要精准归因，不模糊、不越界
异常消息不是日志，它的读者是调用方开发者。一句话要能回答：“谁传错了？错在哪？该怎么改？”
- ✅ 推荐：
"timeoutMs must be > 0, got: -120"（含参数名、期望规则、实际值） - ❌ 避免：
"参数错误"（无上下文）、"非法参数"（术语空洞） - ⚠️ 禁止拼接敏感数据：如密码、token、用户身份证号等，防止意外泄露到监控系统
与 null 校验的分工要清晰
null 是一类特殊非法值，但 Java 社区已有更语义明确的处理方式。
- ✅ 优先用
Objects.requireNonNull(name, "name must not be null")—— 抛NullPointerException，但堆栈干净、JVM 优化友好 - ✅ 字符串非空建议用
StringUtils.isNotBlank(name)（Apache Commons）或自定义工具类 - ❌ 不推荐手写
if (name == null || name.trim().isEmpty())—— 易漏边界、重复造轮子
不替代业务异常，也不混入业务判断
契约只管“输入合法”，不管“业务合理”。一个订单金额为 -100 元，是 IllegalArgumentException；但一个订单金额为 100 万元却超出用户信用额度，那是 BusinessValidationException。
- ✅ 合法性校验：数值范围、非空、格式（如邮箱正则）、枚举字面量匹配
- ❌ 业务性校验：库存是否充足、余额是否足够、权限是否允许 —— 这些应由独立的业务校验层处理
- ⚠️ 混用后果：方法职责膨胀，单元测试难覆盖，API 契约变得模糊且不可靠
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
