go禁止值接收器方法内直接调用同类型指针接收器方法，因值接收者可能是不可寻址副本，隐式取地址会破坏“值方法只读”的语义契约，编译期强制报错。
值接收器方法里直接调用指针接收器方法会报错
不能。Go 编译器明确禁止在值接收器方法内部直接调用同类型的指针接收器方法，因为这会隐式触发取地址操作，而值接收器绑定的对象可能不在可寻址内存位置（比如字面量、map 中的值、函数参数传入的临时副本）。
常见错误现象：cannot call pointer method on ... 或 cannot take the address of ...，尤其在对 struct 字面量或 map value 调用值接收器方法时突然爆出。
- 值接收器方法接收的是副本，编译器无法保证该副本有稳定地址
- 即使 struct 变量本身可寻址（比如局部变量），值接收器方法体内仍被视作“不可寻址上下文”
- 这条限制是编译期强制的，不依赖运行时状态
为什么不让自动取地址：安全性和语义一致性
Go 设计上把“值接收器”和“指针接收器”视为两种不同契约：前者承诺不修改接收者，后者明确允许修改。如果允许值方法内部偷偷取地址并调用指针方法，就破坏了值接收器“只读”的语义预期。
典型翻车场景：
立即学习“go语言免费学习笔记（深入）”；
-
m := MyStruct{}; m.ValueMethod()——ValueMethod内部若调PointerMethod()，m 是栈上副本，取地址后改的不是原值 -
data["key"].ValueMethod()—— map value 不可寻址，连&data["key"]都非法，更别说调指针方法 - 函数参数为
func f(s MyStruct)，s 是纯副本，地址无意义
绕过限制的实操方式：显式传参或重构接收器
真需要复用逻辑时，别硬扛编译器，换种组织方式。
- 把公共逻辑抽成普通函数，接收
*MyStruct或MyStruct作为参数，由值/指针方法各自调用 - 统一用指针接收器——只要类型使用场景中存在修改需求，就全用
func (s *MyStruct) Method()，调用方始终传指针 - 值接收器方法里构造新实例再调指针方法（仅限纯函数式逻辑，且不修改原状态）：
temp := *s; temp.PointerMethod()，但注意这仍是副本操作，不反映原值变化
示例：
func (s MyStruct) ValueMethod() {
// ❌ 编译失败：cannot call pointer method on s
// s.PointerMethod()
<pre class='brush:php;toolbar:false;'>// ✅ 拆出纯函数
doWork(&s)}
func doWork(s MyStruct) { / ... */ }
容易被忽略的边界情况：嵌入字段和接口实现
嵌入字段的接收器类型也受同一规则约束。比如 type A struct{ B }，即使 B 有指针接收器方法，A 的值接收器方法也不能直接调 s.B.PointerMethod()。
接口实现层面更要小心：一个类型同时实现了某接口的值方法集和指针方法集，但接口变量实际存储的是值还是指针，决定了能否调用指针方法。例如：
-
var i Interface = MyStruct{}—— 接口底层存的是值，只能调值接收器方法 -
var i Interface = &MyStruct{}—— 底层存指针，值/指针接收器方法都可用 - 但无论哪种，值接收器方法体内都不能反向去调指针方法
最稳妥的做法是：只要类型有指针接收器方法，对外暴露的变量/参数/返回值尽量统一用指针，避免在值上下文中触发这个限制。
