结构体方法需返回 *T 才能链式调用，因只有指针接收者可修改原实例且保持同一地址；值接收者返回副本，导致前序修改丢失，链式失效。
为什么结构体方法返回 *T 才能链式调用
因为只有指针接收者方法才能修改原结构体状态，且返回 *T 类型值后，后续方法才能继续在同一个实例上被调用。值接收者方法返回的是副本，链式调用时每次都在新副本上调用，前一步的修改彻底丢失。
常见错误现象：obj.SetName("a").SetAge(25) 看似链式，但 SetName 是值接收者 → 返回新副本 → SetAge 修改的是这个副本，原始 obj 的 Name 字段没变，Age 更是完全没写入原始对象。
- 使用场景：构建器模式（
Builder）、配置对象（Config）、ORM 查询链（db.Where(...).Limit(...).Find(&u)） - 如果结构体含 slice、map、channel 或需要修改字段，必须用指针接收者，否则无法真正更新
- 性能影响：返回
*T避免结构体拷贝，尤其当结构体较大时（比如含大 slice）
func (t *T) Method() *T 的写法要点
标准写法就是方法签名声明为指针接收者，并显式返回 return t。不是返回 self 或 this —— Go 没有这类关键字。
示例：
立即学习“go语言免费学习笔记（深入）”；
type User struct {
Name string
Age int
}
func (u *User) SetName(name string) *User {
u.Name = name
return u // ← 必须返回 u，不是 &u（那会取地址两次）
}
func (u *User) SetAge(age int) *User {
u.Age = age
return u
}
- 不能写
return &u：u已经是*User，再取地址变成**User - 不能写
return *u：这会返回值副本，破坏链式语义 - 所有链式方法必须统一用指针接收者 +
return t，混用值接收者会导致链断裂
链式调用中 nil 指针的风险与防护
返回 *T 后，如果上游传入的是 nil，后续方法一执行就会 panic：panic: runtime error: invalid memory address or nil pointer dereference。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
这不是语法问题，而是运行时隐患。容易被忽略的点在于：构造器未检查输入、或中间某步返回了 nil（比如工厂函数失败）。
- 典型错误场景：
var u *User; u.SetName("x")→ 直接 panic - 安全做法：在每个链式方法开头加
if u == nil { return nil }（适合可接受 nil 传播的场景） - 更推荐做法：确保链起点非 nil，比如用构造函数
NewUser()返回初始化后的*User，而不是暴露零值指针 - 不建议在每个方法里做防御性初始化（如
if u == nil { u = &User{} }），会掩盖空指针来源，调试困难
和接口组合使用时的隐含约束
如果想让链式结构体满足某个接口（比如 Setter），要注意：接口变量存储的是具体值，而链式方法返回的是指针，类型必须对齐。
示例：
立即学习“go语言免费学习笔记（深入）”；
type Setter interface {
SetName(string) *User
}
var s Setter = &User{} // ✅ 可赋值
s.SetName("x").SetAge(30) // ✅
- 若接口方法签名返回
User（值类型），而实现方法返回*User，编译报错：cannot use &User{} (type *User) as type Setter - 反过来（接口定义返回
*User，实现返回User）也不行 - 兼容性影响：一旦公开了返回
*T的链式 API，下游就依赖该指针语义；后续改回值接收者会破坏所有调用链
链式调用本身不复杂，难的是从第一个方法开始就统一接收者类型、nil 处理策略和接口契约——这些决定一旦上线，基本没法悄悄改。
