必须用指针接收者：修改字段、结构体大、实现接口要求、使用同步原语时；值接收者适用于小且不可变的只读操作。混用会导致方法集不一致和接口不满足。
什么时候必须用指针接收者
当方法需要修改接收者本身的字段时，func (u User) SetName(name string) 无法生效，因为传入的是副本；只有 func (u *User) SetName(name string) 才能真正写入原始结构体。编译器会强制要求：如果类型有任一方法用了指针接收者，那么调用该方法时，接收者必须可寻址——即不能是字面量或临时值，比如 &User{} 或变量 u（而非 User{}）。
- 结构体包含大字段（如切片、map、channel、大数组）时，值接收者会引发不必要的拷贝，性能下降明显
- 实现接口时，若接口方法签名约定为指针接收者（如标准库
io.Reader的Read方法），而你用值接收者实现，会导致类型不满足该接口 - 同步原语（如
sync.Mutex）必须用指针接收者——它的零值是有效状态，复制后锁状态丢失，mu.Lock()作用于副本毫无意义
值接收者适用的典型场景
值接收者安全、无副作用，适合只读操作且结构体足够小（通常不超过机器字长的 2–3 倍）。例如 type Point struct{ X, Y int }，其方法 func (p Point) Distance(q Point) float64 天然适合值接收者——计算不改自身，参数也是值传入，逻辑对称清晰。
- 基础类型别名（如
type ID string）的方法几乎都用值接收者，语义上它就是“不可变字符串” - 纯函数式方法：比如
func (s String) Upper() String，返回新值，不碰原值 - 并发安全考虑：若多个 goroutine 同时调用某方法，且你不希望它们共享同一块内存（比如避免意外写入），值接收者天然隔离
混用值和指针接收者会出什么问题
Go 不允许对同一类型同时定义值和指针接收者同名方法。但更隐蔽的问题是：如果你在代码中既用 var u User 又用 var u *User，然后分别调用方法，实际绑定的方法集可能不同——值类型 User 只能调用值接收者方法；指针类型 *User 则两者都能调。这会导致行为不一致，尤其在接口断言时容易 panic。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 错误示例：
var u User; var p *User = &u; fmt.Println(u.String(), p.String())—— 若String()只实现了指针接收者，第一句编译失败 - 接口赋值陷阱：
var i fmt.Stringer = u要求User实现String()，若该方法是(*User).String，则u不满足接口，必须写成&u - 嵌入结构体时，嵌入字段的方法提升规则也依赖接收者类型：只有指针嵌入（
*Child）才能提升指针接收者方法
一条够用的判断口诀
先看是否要改字段、是否大、是否实现已有接口。三者占其一，就用指针；都不沾，再看是否希望调用方“看不出你在改它”——想隐藏可变性，就用值；否则统一用指针更省心。标准库里 time.Time 是值接收者的经典例外：它内部是 int64，极小，且设计为不可变，所有“修改”方法（如 Add）都返回新实例。
立即学习“go语言免费学习笔记（深入）”；
type User struct {
ID int
Name string
}
// ✅ 推荐：统一用指针，除非你明确需要值语义
func (u *User) SetName(name string) { u.Name = name }
func (u *User) GetName() string { return u.Name }
// ❌ 混用易错：下面这行会让 User 类型无法满足 Stringer 接口（如果 String 是指针接收者）
// func (u User) String() string { return u.Name }
最常被忽略的是：哪怕结构体现在很小，只要未来可能加字段或需并发控制，一开始就选指针接收者，比后期重构所有调用点成本低得多。
