“在 Go 中，我应该使用 (s T) 还是 (s *T)？”
这恐怕是 Go 开发者（无论新手还是老手）最常问的问题之一。一个错误的选择可能导致代码功能出错、性能低下，或者引入难以察觉的并发 Bug。
本文将为你彻底厘清这两种方式的底层差异，并提供一个清晰的决策框架，帮助你在不同场景下做出正确的选择。
核心区别：副本 vs. 引用
首先，我们必须澄清一个概念：这两种方式的核心区别在于“调用方法时传递了什么”。
-
值接收者（ func (s MyStruct) ValueMethod()）：调用方法时，会传递结构体的副本（Copy）。 -
指针接收者（ func (s *MyStruct) PointerMethod()）：调用方法时，会传递结构体的指针（Pointer）。
你可能会这样调用：
func main() {
v := MyStruct{}
v.ValueMethod()
v.PointerMethod()
}
注意，当你调用 PointerMethod 时，Go 会隐式地取它的地址，底层是这样的：(&v).PointerMethod()。
这个隐式转换是 Go 的语法糖，但它揭示了问题的核心：可变性（Mutability） 和 复制成本（Copy Cost）。
对于值接收者（ValueMethod()），v 到 s 传递，将会复制整个结构体（浅拷贝），s 是 v 的一个全新副本。方法内对 s 的修改，绝不会影响方法外的 v。
对于指针接收者（PointerMethod()）：v 到 s 传递，仅仅复制指针，s 是一个指向 v 的指针。方法内通过 s 修改数据，会直接修改方法外的 v。
决策框架
理解了以上的原理，文章开头提到的问题该如何决策，就有了清晰的思路。这个决策，本质上是关于 代码正确性（可变性） 和 代码性能（复制成本） 之间的权衡。
何时使用指针接收者（*T）
在大多数情况下，指针接收者是 Go 语言的默认和首选。这里是你必须或应该使用它的理由，按重要性排序：
规则一（强制）：当方法需要修改接收者的状态时
这是最重要的一条规则。由于值接收者操作的是副本，任何修改都会在方法返回时丢失。
type Counter struct {
count int
}
// 值接收者：在副本上递增，原始值不变
func (c Counter) IncrementValue() {
c.count++
}
// 指针接收者：在原始值上递增
func (c *Counter) IncrementPointer() {
c.count++
}
func main() {
c := Counter{}
c.IncrementValue()
fmt.Println(c.count) // 输出: 0 (!!!)
c.IncrementPointer()
fmt.Println(c.count) // 输出: 1
}
真实场景举例：bytes.Buffer 的 Write() 方法，ORM 模型的 Save() 方法。
规则二（性能）：当结构体非常大时
如果一个结构体非常大（例如包含一个大数组或许多字段），每次调用方法都复制它，开销会非常大。
// 假设 BigStruct 占用 1MB 内存
type BigStruct struct {
data [1024 * 1024]byte
}
// 性能极差：每次调用都复制 1MB 数据
func (s BigStruct) ReadData() byte {
return s.data[0]
}
// 性能极好：只复制一个 8 字节的指针
func (s *BigStruct) ReadDataPtr() byte {
return s.data[0]
}
真实场景举例：Kubernetes client-go 中的资源对象（如 Pod, Deployment）都非常庞大，几乎总是通过指针传递。
规则三（一致性）：当类型需要保持一致性时
Go 官方推荐：如果一个类型上的任何一个方法需要指针接收者，那么该类型上的所有方法都应该使用指针接收者。
这能避免使用者产生混淆，例如：v.Modify()（指针）和 v = v.ReadOnly()（值）会让人产生疑惑，而实际上它们是两种截然不同的使用模式。因此，保持一致性（要么全是 *T，要么全是 T）能极大提升代码的可读性和可预测性。
规则四（安全）：当结构体包含“不可复制”的字段时
这是一个微妙但关键的安全问题。像 sync.Mutex 这样的类型，在复制后会失效（你等于复制了一个锁，但它们互不相干）。
type SafeCounter struct {
mu sync.Mutex
count int
}
// 危险！调用此方法会复制 Mutex，导致数据竞争
func (sc SafeCounter) Value() int {
sc.mu.Lock()
defer sc.mu.Unlock()
return sc.count
}
// 正确！操作的是同一个 Mutex 实例
func (sc *SafeCounter) ValuePtr() int {
sc.mu.Lock()
defer sc.mu.Unlock()
return sc.count
}
何时使用值接收者（T）
值接收者是特殊的，只应该在少数你有明确意图的场景下使用。
规则一（意图）：当结构体是“值类型”且不可变时
如果你的结构体很小（比如 Point{X, Y}），并且你希望它表现得像 int 或 string 一样的“值”（即传递它时总是得到一个新副本，永远不用担心原始值被修改），那么请使用值接收者。
type Point struct {
X, Y float64
}
// Distance 方法不应该修改 p，它只是一个计算
// 使用值接收者，我们向调用者保证了 p 的安全
func (p Point) Distance(q Point) float64 {
return math.Hypot(p.X-q.X, p.Y-q.Y)
}
真实场景举例：标准库 time.Time。它的 Add() 方法就是值接收者，它返回一个新的 Time 对象，而不是修改原始的 Time。
规则二（特殊）：当结构体是 map、slice、channel 的封装时
像 map[string]int 和 []byte 这样的类型，它们在 Go 中已经是“引用类型”。复制它们的开销非常小（只复制了切片头或 map/channel 的指针），并且它们指向的底层数据是共享的。
例如，下面这种情况：
type MySlice struct {
data []string
}
func (s MySlice) Read() string {
return s.data[0]
}
在这种情况下，从性能角度看，使用值接收者（s MySlice）是完全可行的。但是，根据“一致性规则”（见上面规则三），如果你的结构体上已经有其他方法（比如 Add）使用了指针接收者，那么所有方法都应保持一致，继续使用指针。
总结
为结构体编写方法时，这里有一条非常简单的黄金法则：
始终默认使用指针接收者 (*T)。
只有当你非常明确希望这个结构体表现得像 int 或 time.Time 那样，是一个不可变的小型“值类型”时，才转而使用值接收者 (T)。在绝大多数情况下，指针接收者都能在功能性、性能和一致性上为你提供正确且最优的选择。