链式调用必须用指针接收者，因为只有指针能修改原对象并返回可继续调用的地址；值接收者操作副本且无法取临时值地址，方法返回类型必须是*User而非User，否则后续指针方法调用编译失败。
为什么链式调用必须用指针接收者？
因为只有指针接收者才能修改原对象，且 go 不允许对值类型临时结果取地址——这是链式调用能“串起来”的底层硬约束。
- 值接收者（
func (u User) SetName(...)）操作的是副本，字段修改完全不影响原始变量 - 指针接收者（
func (u *User) SetName(...)）直接写入原内存，保证状态可累积 - 更关键的是：若方法返回值是
User（值类型），后续调用.SetAge()时，Go 编译器会报错cannot call pointer method on ...—— 它无法给一个临时值生成有效地址
方法返回值类型必须是 *T，不是 T
返回 *User 而非 User，不是风格选择，而是语法刚需：只有指针才能继续调用指针接收者方法。
- 错误写法：
func (u *User) SetName(name String) User { u.Name = name; return *u }→ 下一步.SetAge()直接编译失败 - 正确写法：
func (u *User) SetName(name string) *User { u.Name = name; return u }→u是地址，可继续点调用 - math/big 包就是典型范例：
r.Sub(a, b).Mul(c)成立，全靠每个方法都返回*Int
Go 的自动分号插入（ASI）会悄悄破坏链式调用
你以为写成两行就能链？Go 可能已在第一行末尾加了分号，让第二行的 .Method() 变成孤点报错。
- 错误姿势：
user.SetName("Alice")
.SetAge(25)→ 编译报
syntax Error: unexpected . - 正确姿势：点必须跟在上一行末尾，强制 Go 不插分号
user.SetName("Alice")
.SetAge(25) - 构造函数初始化也一样：
NewUser().SetName("A").SetAge(25)必须写在同一行或点续行
什么时候不该强行链式？
链式调用不是银弹。它简化的是“无副作用、顺序执行、不需中断”的配置流；一旦涉及错误处理或条件分支，硬链反而埋坑。
立即学习“go语言免费学习笔记（深入）”；
- 返回
error的方法（如io.Read）无法自然融入链，强行包装会掩盖错误传播路径 - 某个方法内部 panic 或提前 return，后续调用就永远执行不到，调试困难
- 结构体字段被并发读写时，链式调用不提供任何同步保障，
u.SetX(x).SetY(y)并非原子操作
链式调用真正难的不是写法，而是判断哪条链值得建、哪条链该拆开——尤其是当方法开始承担业务逻辑而非纯状态设置时，那个 return u 就从语法糖变成了责任边界模糊的信号。