建造者模式专为参数组合不可控、必填/可选边界模糊而设计；其核心是将完整性校验前置到build()，强制私有构造、链式赋值无副作用、语义分组复合方法、build()唯一校验并创建不可变对象。
建造者模式不是为“参数多”而存在，而是为“参数组合不可控 + 必填/可选边界模糊”而设计。当一个业务对象有十几个甚至几十个字段，其中部分必填、部分有条件生效、部分互斥或依赖另一字段时，直接用构造函数或 setter 链都会导致调用混乱、状态不一致、校验滞后等问题。builder 的核心价值，在于把对象完整性校验从运行时提前到 build() 调用那一刻，并让必填约束在代码流中自然浮现。
必须封死构造入口，只留 Builder 入口
Product 类（如 Email、ServerConfig）的构造函数必须是 private，且只接受 Builder 实例或其内部结构（如数组）作为唯一参数。不能暴露 public 构造器，否则绕过 Builder 直接 new 就会破坏契约。同时，静态工厂方法（如 Email::create()）必须返回 Builder 实例，而不是 Product 或中间态对象。这是保证构建过程受控的第一道防线。
链式方法只赋值、不执行副作用
所有 setXxx() 方法必须满足两个条件：
- 仅做属性赋值，返回 $this，支持连续调用
- 不触发任何外部操作（如 DNS 查询、连接测试、远程鉴权）
比如 setHost() 只存字符串，enableTLS() 只标记开关；真实校验和初始化动作应交给 build() 或后续独立的 validate() / connect() 方法完成。
按语义分组 + 提供快捷复合方法
面对三十多个字段，平铺 setXxx() 会让 IDE 补全失效、阅读成本陡增。真实配置天然分层：
- 网络层：host、port、timeout、tlsEnabled
- 认证层：token、secret、region、scope
- 行为层：retryTimes、maxConns、autoFlush
- 日志层：logLevel、traceId、samplingRate
应在 Builder 中提供 withNetwork()、withAuth()、withRetry() 等复合方法，内部封装多个原子 set 调用，既提升可读性，也便于未来统一调整逻辑。
build() 是唯一校验点，也是对象诞生时刻
build() 方法承担三重责任：
- 检查必填字段是否已设置（如 host、token 缺一不可）
- 验证字段间依赖关系（如 timeout > 0 仅当 tlsEnabled === true）
- 一次性将所有参数传入 Product 私有构造器，生成不可变对象
不在此处做远程有效性检查（如 API key 是否真实可用），那是业务层职责，不属于构建阶段。校验失败应抛出 InvalidArgumentException，而非静默降级或默认填充。
