直接 new Config() 会崩溃，因12+可选字段易拼错、漏设必填项、新增字段需全量修改，且TS类型推导变宽泛；Builder模式须在build()中集中校验必填项、数值范围及结构，并返回Object.freeze后的Readonly。
为什么直接 new Config() 会崩溃
当配置对象有 timeout、retries、headers、authToken、logLevel、proxyUrl、maxBodySize 等 12+ 个可选字段时，用构造函数或对象字面量初始化极易出错：
– 字段名拼错（比如 timeOut 写成 timeout）不会报错，但逻辑失效
– 必填项漏设（如 baseUrl）要等运行时请求失败才暴露
– 新增字段后，所有调用点都要改，没法增量演进
– TypeScript 类型推导在深度嵌套可选字段下也容易变宽泛，失去约束力
Builder 实现必须带 build() 校验环节
建造者模式不是“加一堆 setXXX() 就完事”，关键在 build() 方法里做集中校验。否则只是把“参数混乱”换成“状态混乱”。
常见做法包括：
-
build()中检查必填字段是否已设置（如if (!this.baseUrl) throw new Error("baseUrl is required")） - 对数值类字段做范围检查（如
if (this.timeout 30000) throw new Error("timeout must be 0–30000ms")） - 对数组/对象类字段做非空或结构验证（如
Array.isArray(this.headers)） - 避免在 setter 中立即校验——那样会破坏链式调用的原子性
JavaScript 中链式调用必须 return this，但别忘了冻结最终对象
JS 的 builder 很轻量，但容易忽略两个细节：
– 每个 setter 必须 return this，否则链式中断
– build() 返回的对象不应再被意外修改，否则破坏封装性
推荐写法：
build() {
if (!this.baseUrl) throw new Error("baseUrl is required");
const result = Object.assign({}, this);
return Object.freeze(result); // 防止后续篡改
}
不推荐直接返回 this，那会暴露 builder 实例内部状态；也不推荐用 Object.seal()，它允许属性值变更，而 freeze 更符合“构建完成即不可变”的语义。
TypeScript 下 Builder 类型需显式声明返回类型
TS 默认会把链式调用的返回类型推导为 any 或过宽的联合类型，导致类型检查失效。必须手动标注：
setBaseUrl(baseUrl: string): this { ... }
setTimeout(timeout: number): this { ... }
build(): Readonly<Config> { ... }
否则即使写了 const cfg = new ConfigBuilder().setBaseUrl("...").build();，后续访问 cfg.timeout 也可能没提示或误报 undefined。
更稳妥的做法是：让 build() 返回一个明确的 interface Config，且该 interface 不含可选字段的 ? —— 所有可选字段在校验后应视为“已确定存在或明确为 undefined”，由 builder 内部逻辑保证。
真正难的不是写出 setXxx → build 这几步，而是判断哪些字段该强制校验、哪些该默认填充、哪些该在 build 前合并（比如多次调用 setHeader() 应累积而非覆盖）。这些逻辑一旦散落在各处，builder 就退化成语法糖。它最核心的价值，是把“对象有效性”的责任收束到一个可控入口点。
