根本原因在于接收者是否能修改原值并维持地址连续性：值接收者(t)每次调用都复制新对象，返回的t指向临时副本，地址无效；指针接收者(t)操作原始内存，返回自身地址，才能安全链式。
为什么 func (*T) Method() *T 能链式调用，而 func (T) Method() *T 不行
根本原因在于接收者是否能修改原值并维持地址连续性。值接收者 (T) 每次调用都复制一份新对象，返回的 *T 指向的是临时副本，下一次调用时这个地址可能已失效或与原始实例无关；指针接收者 (*T) 操作的是原始内存地址，返回 *T 就是返回自身地址，才能安全串联。
常见错误现象：cannot call pointer method on t (type T) 或链式后半段操作没生效（比如字段没变），本质是误用了值接收者却期待状态延续。
- 只要你想在链式中“保持状态变更”，接收者必须是
*T - 如果方法本身不修改字段（纯计算），用
T也行，但无法真正链式——因为下个方法调用时拿不到你上一步返回的那个*T实例的可变上下文 - 结构体含 slice/map/chan 等引用类型时，值接收者看似“能改”，实则改的是副本里的引用，原 slice 底层数组不变，容易误判为链式有效
如何让 Builder 类型支持 SetX().SetY().Build()
这是最典型的链式调用场景。关键不是“返回 *T”，而是每个方法都返回 *T 且接收者是 *T，形成地址闭环。
示例：
立即学习“go语言免费学习笔记（深入）”；
type Config struct {
host string
port int
}
func (c *Config) WithHost(h string) *Config {
c.host = h
return c // 返回当前指针，不是 new(Config)
}
func (c *Config) WithPort(p int) *Config {
c.port = p
return c
}
func (c *Config) Build() *Config {
return c
}
使用：c := &Config{}.WithHost("localhost").WithPort(8080).Build()。注意初始化必须是 &Config{} 或 new(Config)，否则 Config{} 是值，无法取地址传给 (*Config).WithHost。
- 所有链式方法必须是
func (*T) ... *T形式，不能混用值接收者 - 避免在中间方法里
return &T{...}—— 这会断掉链，新地址和前面无关 - 如果某个方法需要“不可变语义”，就别设计成链式，Go 不靠链式保证 immutability
链式调用 + 接口组合时，*T 方法集和 T 方法集的区别
接口赋值依赖方法集。定义 type Setter interface { SetX(x int) *T }，只有 *T 实现了该方法，T 没有——即使你写了 func (T) SetX(int) *T，它也不在 T 的方法集中（因为返回的是 *T，而接收者是值，Go 不允许值接收者方法返回指针并被接口接受，除非接口方法签名完全匹配）。
常见错误：把 var t T 传给期望 Setter 的函数，报错 T does not implement Setter (SetX method has pointer receiver)。
- 接口变量要存
*T，不是T；否则方法集不匹配 - 如果想让
T和*T都能赋值给同一接口，接口方法接收者必须统一为T，但这就没法链式（返回*T无意义） - 别试图用类型别名绕过：Go 中
type MyT T不继承T的方法集
性能与逃逸：每次 return c 会不会导致额外堆分配？
不会。返回局部指针 c（即接收者本身）不会触发新分配，编译器清楚这个指针指向调用方传入的堆/栈地址。但要注意：如果链式调用嵌套过深，或中间有闭包捕获，可能促使原本在栈上的 *T 逃逸到堆。
验证方式：go build -gcflags="-m" main.go，看是否有 ... escapes to heap 提示。
- 单次方法返回
return c几乎零开销，就是传回寄存器里的地址值 - 真正影响性能的是链式中做了大量非必要字段赋值，或误用
append导致底层数组反复扩容 - 如果结构体很大（>128B），值接收者会有明显拷贝成本，此时指针接收者+链式反而是更优解
链式调用本身不复杂，难的是判断什么时候该用、什么时候不该用——尤其是当方法开始有条件分支、error 返回、或需要兼容 nil 接收者时，*T 的空指针 panic 就比 T 的静默失败更难调试。
