链式调用必须返回 t 而不是 t，因为值接收器操作副本，无法持久化修改；只有指针接收器配合返回 t 才能确保后续方法基于最新状态执行，且所有方法须统一使用 *t 接收器并返回自身指针。
为什么链式调用必须返回 *T 而不是 T
因为值接收器方法修改的是副本，调用后原对象不变，后续方法无法基于最新状态继续操作。只有指针接收器才能真正更新字段，且返回 *T 才能让下一次调用“接着上一次改完的状态”往下走。
常见错误现象：obj.SetX(1).SetY(2) 看似链式，但 SetX 返回的是新副本，SetY 实际作用在旧副本上，最终 obj 的 Y 没变。
- 接收器类型必须是
*T（不能是T） - 每个方法签名末尾统一写
return *t或return t（t是*T类型变量） - 初始化时得用
&T{}或NewT()，否则普通字面量T{}无法取地址用于链式起点
如何定义一个可链式调用的结构体和方法
核心是统一返回 *T，且所有方法都设计为“只改字段 + 返回自身指针”。不需要额外接口或泛型封装。
使用场景：构建器模式（如 HTTP client 配置）、状态累加操作（如字符串格式化器）、测试用对象组装。
立即学习“go语言免费学习笔记（深入）”；
示例：
type Config struct {
host string
port int
tls bool
}
func (c *Config) WithHost(h string) *Config {
c.host = h
return c
}
func (c *Config) WithPort(p int) *Config {
c.port = p
return c
}
func (c *Config) WithTLS(on bool) *Config {
c.tls = on
return c
}
调用：c := &Config{}.WithHost("api.example.com").WithPort(443).WithTLS(true)
链式调用中容易忽略的 nil 指针风险
如果某个方法内部可能返回 nil（比如条件构造、错误提前退出），整个链会在该点 panic。Go 不做空值短路，nil.WithX() 直接崩溃。
性能影响：无额外分配，所有方法都在原内存地址操作，比每次返回新结构体更轻量。
- 禁止在链式方法中返回
nil—— 即使逻辑上想“跳过”，也应返回c - 若需条件分支，把判断提到链外：
if needTLS { c = c.WithTLS(true) }，而不是在WithTLS内部返回nil - 构造函数（如
NewConfig()）应确保返回非 nil 指针，避免链起点就崩
与函数式风格（返回新值）的关键区别
Go 的链式调用本质是命令式更新，不是函数式不可变。这意味着同一变量多次链式调用会相互覆盖，不是叠加历史。
常见误解：以为 a.SetX(1).SetX(2) 是“先设1再设2”，确实如此；但 b := a.SetX(1); b.SetX(2) 和 a.SetX(2) 效果完全一样 —— 因为都改的是同一块内存。
- 没有“中间快照”，所有调用共享底层状态
- 不适合并发安全场景：多个 goroutine 同时链式调用同一实例会竞态
- 如果需要不可变语义，别用链式，改用返回新
T的纯函数风格
真正麻烦的地方不在写法，而在于团队是否理解——这个“链”不是语法糖，它绑定了可变性、生命周期和并发约束。一不留神，调试时发现值被别处改了，却找不到源头。
