大厂推荐在复杂实体类用@builder，因其提升创建确定性、可读性与可维护性；可避免参数顺序错乱、构造器爆炸，显式表达字段意图，支持不可变设计与构建时校验，并便于测试复用。
大厂规范推荐在复杂数据实体类上使用 @Builder，核心原因不是为了“写得少”，而是为了提升对象创建的确定性、可读性和可维护性——尤其当字段数超过 5 个、存在必填/可选混杂、或需支持未来扩展时。
避免参数顺序错乱与构造器爆炸
传统全参构造函数在字段增多后极易出错：多个 String 或 int 类型参数并列时，调用方无法从位置判断语义；新增字段还要同步修改所有构造调用点。@Builder 将字段名直接暴露为方法名（如 .userId("u123")），彻底消除位置依赖，也规避了重载构造器泛滥的问题。
显式表达字段意图，区分必填与可选
Builder 链式调用天然支持“按需赋值”。开发人员一眼能看出哪些字段被设置、哪些被跳过；配合 @Builder.Default，还能清晰声明默认行为（例如 @Builder.Default private Map<string object> metadata = new HashMap();</string>）。这比在构造函数里硬编码默认值或靠文档说明更可靠、更易被 IDE 和静态检查工具识别。
天然适配不可变设计与防御性编程
大厂服务普遍要求 DTO/VO/State 类具备不可变性（final 字段 + 无 setter）。@Builder 可直接作用于 全参构造函数（而非类上），生成的 Builder 在 build() 时一次性初始化 final 字段，既保证线程安全，又避免了 setter 破坏封装。同时，你可以在自定义 Builder 的 build() 方法中加入校验逻辑（如非空检查、范围限制），把校验前移到构建阶段，而不是等到运行时抛异常。
便于测试与组合场景
单元测试中常需构造大量相似但仅个别字段不同的对象（如“成功态”“失败态”“超时态”）。用 Builder 可基于一个基础实例快速派生：
User base = User.builder().tenantId("t1").env("prod").build();
User success = base.toBuilder().status("SUCCESS").build();
User timeout = base.toBuilder().status("TIMEOUT").timeoutMs(5000).build();
这种复用方式比重复写 builder 链更简洁，也比反射或手动 copy 更类型安全。
