值接收者无法修改原结构体字段，指针接收者才能修改；这是内存模型的刚性约束，涉及方法集、接口实现、性能开销与并发安全。
值接收者改不了原结构体字段，指针接收者才能改；这不是语法糖问题，是内存模型的刚性约束。
func (h Holder) SetMember 和 func (h *Holder) SetMember 行为完全不同
前者每次调用都复制整个 Holder 到栈上，h.i = i1 只动副本；后者传的是地址，h.i = i1 直接写回原始内存位置。你可以用 &c 和 &h 打印地址验证——值接收者下两者地址必然不同，指针接收者下一致。
- 结构体含切片、map、大数组或超过 3–4 个字段时，值接收者会触发明显拷贝开销
- 哪怕方法只读，若结构体含指针字段（如
data *[]byte），值接收者仍共享底层数据，不等于“安全” - Go 不允许你在同一类型上混用两种接收者实现同一逻辑（比如一个
Update()用值、另一个Reset()用指针），否则接口实现会断裂
指针接收者影响接口实现：*T 能实现接口，T 不一定行
接口方法集规则很硬：类型 T 的方法集只包含定义在 T 上的方法；类型 *T 的方法集包含定义在 T 和 *T 上的所有方法。所以如果接口要求的方法是 func (t *T) Save()，那只有 *T 变量能赋给该接口变量，T 字面量直接报错：cannot use t (type T) as type Saver in assignment: T does not implement Saver (Save method has pointer receiver)。
- 常见坑：把
var s Saver = MyStruct{}写成值，但接口方法全是*MyStruct接收者 → 编译失败 - 修复方式不是加括号强制取址（
&MyStruct{}），而是统一声明为指针：var s Saver = &MyStruct{} - 嵌入匿名字段时尤其危险：若嵌入的是
T，而外部想用*T方法，嵌入不会自动提升指针接收者
调用时编译器自动解引用，但底层语义没变
t.Method() 看似统一，实际是语法糖：Method 定义在 *T 上时，编译器悄悄转成 (&t).Method()；定义在 T 上时，pt.Method() 会被转成 (*pt).Method()。但这不改变本质——值接收者仍是复制，指针接收者仍是直写。
立即学习“go语言免费学习笔记（深入）”；
- 别因为语法糖就忽略接收者类型：它决定方法能否修改状态、是否满足接口、是否引发意外拷贝
- 并发场景下，指针接收者方法若修改共享字段，必须自己加锁；值接收者看似“线程安全”，但改的只是副本，对业务状态无意义
- 小结构体（如
type Point struct{ X, Y int }）用值接收者没问题，但一旦加个label string，就得重新评估——string底层是 struct，含指针，值接收者仍会复制指针而非内容
最易被忽略的点是：接收者类型不是“怎么写方便”，而是“你承诺了什么”。值接收者 = 向调用方承诺“我绝不改你”，指针接收者 = “我有权改你，你得负责同步”。这个契约一旦定下，就牵动接口、并发、性能三根线，改起来成本远高于初写时多敲一个 *。
