Go中链式调用易出错，因值接收者复制结构体、非指针返回导致状态丢失；所有中间方法须返回*Builder，Build()为唯一出口且只做内存内操作。
为什么 Go 里直接写 obj.DoA().DoB().DoC() 容易出错
Go 没有隐式引用传递，方法接收者如果是值类型，每次调用都会复制结构体；如果返回的是新实例（而非指针），链式调用会丢失中间状态。常见错误是：看似链式，实际每步都在操作副本，最后结果没变。
- 接收者用
*Builder，不是Builder—— 否则SetX()修改的是副本 - 所有链式方法必须返回
*Builder，不能返回Builder或error - 不要在链中混入可能 panic 的操作（比如未校验的
json.Unmarshal），否则链断裂且无提示
Builder 方法必须统一返回 *Builder 才能连起来
这是链式调用的硬性前提。Go 不支持运算符重载或隐式转换，链能否成立，只看函数签名是否“接得上”。一旦某个方法返回 error 或 string，链就断了。
- 正确写法：
func (b *Builder) WithName(name string) *Builder - 错误写法：
func (b *Builder) Validate() error—— 这个没法接在链尾，得单独调 - 折中方案：把校验拆成两步，
Validate()独立调，或用Build()统一收口并返回(Result, error)
Build() 是唯一该返回最终对象或 error 的方法
Build() 是 Builder 模式的出口，不是链中普通一环。它不返回 *Builder，而是负责校验、组装、转换，并给出最终结果。这里最容易踩的坑是：在 Build() 里做耗时操作（如网络请求、文件读取），导致链式接口失去“轻量构造”的本意。
-
Build()应只做内存内操作：字段校验、结构体填充、简单转换 - 如果需要异步/IO，应提供独立方法如
BuildAndSend()，不塞进链式路径 - 示例：
b.WithURL("http://a.b").WithTimeout(5).Build()返回(*Request, error)，不是*Builder
别让 Builder 变成“万能配置器”
链式调用容易诱使开发者把所有可配项都塞进 Builder，结果出现十几个 WithXXX 方法，部分参数逻辑互斥（比如 WithTLS() 和 WithInsecure()），但编译器无法约束。这时类型系统帮不上忙，靠文档和调用方自觉，很脆弱。
立即学习“go语言免费学习笔记（深入）”；
- 对互斥选项，用不同 Builder 类型更好，比如
HTTPClientBuilder和HTTPClientInsecureBuilder - 对必填字段，可在
Build()中检查，但更早的防御是：用私有字段 + 非导出构造函数，强制走NewBuilder()起手 - 真正难处理的是“顺序敏感”逻辑（比如必须先
WithPath()再WithQuery()），Go 无法在类型层面表达，只能靠注释和测试覆盖
链式调用看着干净，但每一步的副作用、接收者类型、返回类型、错误处理时机，都得亲手对齐。稍有松动，链就断得无声无息。
