值接收者方法能被指针调用，但指针接收者方法不能被值调用
Go 会自动对指针做解引用（*p）来调用值接收者方法，所以 p.Method() 可以成功——只要 Method 是值接收者。反过来，如果方法是 func (p *T) M()，而你写 t.M()（t 是 T 类型变量），编译器直接报错：cannot call pointer method on t 或 cannot take address of t（尤其当 t 是临时值时）。
常见错误现象：
- 传入 struct 字面量或函数返回的临时 struct 值，却想调用指针接收者方法
- 接口赋值失败：某个接口要求实现
*T的方法，但你只传了T值
实操建议：
- 如果类型需要修改自身字段，或方法内部要取地址（比如传给
sync.Mutex.Lock()），必须用指针接收者 - 如果方法只读、不修改，且类型不大（如
int、小 struct），值接收者更轻量；但一致性更重要——同一类型的方法接收者风格尽量统一 - 定义接口前，先确认实现类型的接收者类型；接口变量赋值时，检查左边是
T还是*T -
var i fmt.Stringer = &t; fmt.Println(i.String())成功，但var i fmt.Stringer = t失败（若String()是指针接收者） -
type A struct{ B *B }; a.B.Field可以，但a.B.Method()若Method是值接收者，Go 不会自动解引用a.B再调用——它本来就是指针，调用没问题；但如果写成(*a.B).Method()就多余了 - 不要指望自动解引用能绕过类型系统约束；接口实现关系是静态确定的，和运行时值无关
- 嵌套结构体中，字段类型是
*T还是T，直接影响你能调用哪些方法——和顶层变量是值还是指针无关 - 用
go vet可捕获部分“本该用指针却传了值”的潜在问题 - 给
[]int定义了指针接收者方法func (s *[]int) Push(x int)，结果s.Push(1)报错，因为s是值，不能取地址 - 误以为
map值接收者方法能避免修改原 map，其实 map 值本身就是引用句柄，改内容就是改原 map - 除非真要修改 slice header 本身（如扩容后替换原 slice），否则别给 slice/map 等定义指针接收者方法——值接收者已足够，也更自然
- 如果方法要重分配底层数组（如自定义 slice 扩容逻辑），必须用指针接收者，且调用方必须传地址
- 记住：值接收者 ≠ 值拷贝语义，对引用类型来说，值接收者也能修改底层数据
- 设计可导出 API 时，优先考虑值接收者，除非明确需要修改状态
- 如果类型必须隐藏构造过程（如用工厂函数返回
*T），那就统一用指针接收者，避免用户误以为可以安全复制值 - 嵌入匿名字段时，若父 struct 要调用子 struct 的方法，接收者类型必须匹配——嵌入
T不能调用*T方法，除非显式取地址
自动解引用不是类型转换，它不改变方法集归属，也不影响地址可取性。最容易被忽略的是：临时值（比如函数返回的 struct、字面量）永远无法取地址，因此绝不可能调用指针接收者方法——连编译都过不去。
自动解引用只发生在方法调用时，不适用于接口断言或字段访问
Go 的自动解引用是语法糖，仅限于「方法调用」这一种场景。它不会帮你把 *T 自动转成 T 去匹配接口类型，也不会在结构体嵌套中穿透指针去访问字段。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：
实操建议：
切片、map、channel、func、interface 类型本身是指针包装，不适用这套规则
这些类型在底层都是包含指针的头结构（header），所以它们的值接收者方法本质上操作的是共享底层数组/哈希表等。你传 slice 还是 &slice，对元素修改的影响是一样的——但方法能否被调用，仍受接收者规则约束。
常见错误现象：
实操建议：
struct 包含 unexported 字段时，指针 vs 值接收者影响可嵌入性
如果一个 struct 有未导出字段，它无法被其他包直接实例化。此时若你用指针接收者定义方法，外部包即使拿到 *T 指针，也无法创建新值；但值接收者方法至少允许外部包通过组合方式间接复用逻辑。
实操建议：
