Golang方法接收者用值还是指针_方法接收者选择原则

必须用指针接收者：修改字段、结构体大、实现接口要求、使用同步原语时；值接收者适用于小且不可变的只读操作。混用会导致方法集不一致和接口不满足。

什么时候必须用指针接收者

当方法需要修改接收者本身的字段时，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。

• 错误示例：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）都返回新实例。

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 }

最常被忽略的是：哪怕结构体现在很小，只要未来可能加字段或需并发控制，一开始就选指针接收者，比后期重构所有调用点成本低得多。