func (t Type) Method() Type 是链式调用的唯一可靠写法，因需返回指针确保操作同一对象、避免副本丢失修改、支持状态变更，且必须规避nil返回和嵌入类型方法未提升等问题。
为什么 func (t *Type) Method() *Type 是链式调用的唯一可靠写法
Go 没有方法链式调用的语法糖，全靠返回接收者指针实现。如果你返回值是 Type（值类型），下一次调用会作用在副本上，原对象不变；更糟的是，如果方法里修改了字段，那些修改直接丢进黑洞——因为没人再持有它。
- 必须用
*Type作返回类型，确保后续调用仍操作同一内存地址 - 接收者也得是
*Type，否则无法在链中修改状态（比如SetX(x).SetY(y)） - 如果类型不可寻址（比如字面量或函数返回的临时值），
t.Method()会编译失败，这是常见报错：cannot call pointer method on ...
链式调用里最容易被忽略的 nil 指针 panic
一旦某个中间方法返回 nil，后面的方法调用立刻 panic：panic: runtime error: invalid memory address or nil pointer dereference。这不是设计缺陷，而是 Go 明确把“空值是否允许参与链式”交给你判断。
- 不要让任何链式方法返回
nil，哪怕逻辑上想表示“跳过”，也该返回self（即return t） - 如果真要支持条件跳过，用布尔参数或拆成两个独立方法，比如
WithTimeout(d time.Duration)和WithoutTimeout()，而不是在内部 return nil - 测试时务必覆盖链中任意一个方法返回前 panic 的路径，比如传入非法参数导致提前 return nil
什么时候不该强行链式：Builder 模式比链式更清晰
当方法职责差异大、参数多、或存在必填/选填约束时，硬套链式会让调用方困惑。比如构造 HTTP 请求，req.SetURL().SetMethod().AddHeader().SetBody() 看似流畅，但 SetBody() 如果接受 []byte 和 io.Reader 两种类型，就容易引发歧义和类型断言错误。
- 优先考虑 Builder 模式：用单独的
RequestBuilder类型封装状态，最后用Build()返回最终对象 - 链式只适合“同质操作”：比如配置类方法（
WithDebug().WithTimeout().WithRetry()），所有方法语义一致、副作用可控 - 如果某个方法需要返回非自身类型（如
Do() error或Exec() (*Result, error)），它天然就是链的终点，别强加return t
嵌入结构体时链式调用的陷阱：匿名字段不自动继承链式方法
你写了 type Client struct{ *HTTPClient }，并给 *HTTPClient 定义了一堆链式方法，但 client.WithTimeout().WithDebug() 会报错：client.WithTimeout undefined (type *Client has no field or method WithTimeout)。Go 不会把嵌入类型的链式方法“提升”为外层类型的方法链。
立即学习“go语言免费学习笔记（深入）”；
- 必须手动为
*Client实现每个链式方法，内部转发给t.HTTPClient，且返回*Client而不是*HTTPClient - 如果嵌入多个可链式类型，更要小心返回类型一致性——不能一个方法返回
*Client，另一个返回*Logger - 别依赖 go vet 或 staticcheck 提醒这类问题，它们不会检查链式返回类型是否匹配外层类型
