链式调用 Builder 模式中属性未校验的根本原因是校验逻辑未在 build() 方法中统一触发，常见于校验遗漏、位置错误或绕过 build() 流程；应确保所有必填与约束校验集中于 build() 内执行，并覆盖组合逻辑与边界场景。
链式调用 Builder 模式中属性未校验，本质是校验逻辑没在构建完成前触发，常见于校验被遗漏、放错位置或绕过了验证入口。排查需聚焦“校验时机”和“构建出口”两个关键点。
检查 build() 方法是否承担最终校验责任
Builder 模式中，唯一可信的校验入口通常是 build() 方法。如果校验分散在 setter 中（如 setAge(int age) 里抛异常），容易被跳过（例如反射赋值、序列化还原、或直接 new Builder() 后只调部分方法）。
- 确认 build() 内部是否显式调用 validate() 或执行字段合法性判断（如 null 检查、范围校验、状态约束）
- 避免仅依赖 setter 校验：setter 只做轻量预处理（如自动装箱、trim），不替代 build 时的终局校验
- 示例错误写法：setEmail(String e) { if (e == null) throw new IllegalArgumentException(); } → 邮箱仍可能为 null（如通过字段直赋、反序列化 bypass）
确认对象实例化是否绕过了 build() 流程
未校验常因对象不是通过 build() 创建，而是走了其他路径：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 检查是否有 public 构造器或 static 工厂方法直接 new 实例（绕过 Builder）
- 排查 JSON 反序列化（如 Jackson）是否启用了无参构造 + 字段注入（@JsonCreator 缺失或 @JsonProperty 误配）
- 留意 Lombok 的 @Builder 注解：默认生成无参 builder() + build()，但若同时加了 @AllArgsConstructor 或 @RequiredArgsConstructor，可能被误用
验证校验逻辑是否覆盖全部必填/约束字段
即使 build() 有校验，也可能漏掉新增字段或复杂约束：
立即学习“Java免费学习笔记（深入）”；
- 逐个比对 Builder 的所有 setter 字段与 build() 中的校验项，确保无遗漏（尤其 boolean、int 等基本类型默认值易被忽略）
- 检查组合约束是否生效，例如：“status = ACTIVE 时，deadline 必须非空”，这类逻辑常被写成独立 setter 校验，实际应放在 build() 中统一判断
- 启用单元测试覆盖边界场景：空字符串、负数、非法枚举值、null 对象等传入后，build() 是否准确抛出预期异常
借助注解或工具提前暴露问题
被动排查不如主动防御：
- 在 Builder 类字段上加 JSR-303 注解（@NotNull, @Min, @Pattern），再配合 Validation.buildDefaultValidatorFactory().getValidator() 在 build() 中 validate(this) —— 利用标准校验框架减少手写疏漏
- 使用 Lombok 的 @Builder(builderMethodName = "builder", buildMethodName = "build") + 自定义 build() 方法，在其中插入校验（注意 Lombok 默认 build() 是 final 的，需禁用默认生成）
- 静态代码检查：用 SonarQube 或自定义 Checkstyle 规则，扫描 Builder 类中是否存在 setter 有校验但 build() 无校验的模式
