builder模式专为解决参数组合不可控与必填/可选边界模糊而设计，通过私有构造、静态工厂、链式setter及build时校验保障对象完整性与不可变性。
Builder 模式不是为“参数多”而存在，而是为“参数组合不可控 + 必填/可选边界模糊”而存在
直接上 __construct() 塞 20 个参数，PHP 会报 Too many arguments 或根本无法维护；用 setter 链式调用看似灵活，但对象可能在 build() 前就处于非法状态（比如漏设 host 却已调用 send()）。Builder 的真正价值，在于把「校验时机」从运行时提前到构建完成那一刻，并把「必填项约束」显式编码进类型系统或方法流中。
PHP 中 Builder 类必须强制封装私有构造 + 静态工厂入口
否则无法保证对象不可变性和构建完整性。常见错误是把 Builder 写成普通工具类，或让 Product 的构造函数 public —— 这会让绕过 Builder 直接 new 成为可能，破坏契约。
-
Email类的构造函数必须是private，且只接受EmailBuilder实例或其内部结构（如数组）作为参数 -
Email::create()必须返回EmailBuilder实例，不能返回$this或其他中间态对象 - 所有字段设为
private，只提供getXXX()，禁用setXXX() - Builder 内部用数组或属性暂存值，
build()时一次性传入new Email(...)，不暴露中间状态
链式调用方法必须全部返回 $this，且避免副作用
比如 setHost() 只负责赋值并返回 $this，不能在里面做 DNS 解析、连接测试等操作；否则 build() 就不再是纯构建动作，而变成带 IO 的“初始化”，违反 Builder 职责单一原则。
- 布尔开关建议用无参方法：如
enableTLS()、disableLogging()，比setTLS(true)更语义清晰 - 可选参数默认值应在
Builder的构造函数里初始化（如Port: 8080），不在Product构造函数里硬编码 - 不要在
build()里做远程校验（如检查 API key 是否有效），那是validate()或connect()的事 - 如果某字段依赖另一字段（如
timeout仅在TLS启用时生效），应在build()中统一校验并抛出InvalidArgumentException
数十个参数时，必须按语义分组并提供快捷方法
全平铺 30 个 setXxx() 方法会让 IDE 自动补全失效、阅读成本陡增。真实业务配置往往天然分层：网络层（host/port/tls）、认证层（token/secret/region）、行为层（timeout/retry/maxConns）、日志层（level/traceId）。
- 在
ServerConfigBuilder中提供withNetwork(...)、withAuth(...)等复合方法，内部调用多个setXxx() - 允许部分字段延迟设置：如
withAuth()->useApiKey($key)->useRegion($r)返回子 builder，再回到主 builder 继续链式调用 - 对高频组合预置静态方法：
ServerConfigBuilder::production()、::localDev()，内部调用预设值链 - 避免过度抽象：不需要为每个字段配一个接口（如
HostSetter），PHP 不支持泛型，接口只会增加调用噪音
最易被忽略的一点：Builder 本身不是配置容器，它只是构建指令的收集器。一旦调用 build()，Builder 实例应视为已消费，不应复用或二次调用 build() —— 否则容易因内部状态残留导致对象不一致。
