根本原因是go方法集规则：值类型t的方法集仅含t接收者方法，而指针类型t的方法集包含t和 t接收者的所有方法；若接口方法有t接收者，则只有t实现该接口。
为什么 myStruct{} 不能赋值给接口，但 &myStruct{} 可以
根本原因不是“写法不对”，而是 Go 编译器严格按方法集（method set）规则校验接口满足关系。值类型 MyStruct 的方法集只包含接收者为 MyStruct 的方法；而指针类型 *MyStruct 的方法集同时包含接收者为 MyStruct 和 *MyStruct 的所有方法。
所以：如果接口中任意一个方法的接收者是 *MyStruct，那么只有 *MyStruct 类型才拥有该方法——MyStruct{} 值本身不“拥有”它，哪怕你能写 myStruct.Value()（那是编译器自动加了 & 的语法糖，不改变类型归属）。
- 错误现象：
cannot use myStruct{} (type MyStruct) as type MyInterface in assignment: MyStruct does not implement MyInterface (Value method has pointer receiver) - 正确做法：传
&myStruct{}，或声明变量后取地址：var m MyStruct; var _ MyInterface = &m - 别依赖 IDE 提示——它只比对方法签名，不检查接收者类型是否落入该类型的方法集中
如何快速验证某个类型是否真正实现了接口
最可靠、零运行时开销的方式，是在任意函数内加一行编译期断言：
var _ MyInterface = (*MyStruct)(nil)
如果编译通过，说明 *MyStruct 确实实现了 MyInterface；报错则直接指出缺哪个方法、接收者类型是否匹配。这比 reflect.TypeOf(t).Implements() 更准，后者在运行时无法区分值/指针接收者差异。
- 想验证值类型实现？用
var _ MyInterface = MyStruct{}（仅当所有方法都是值接收者时才可能成功） - 若接口来自标准库（如
io.Writer），可直接查 pkg.go.dev 文档，看其实现要求——比如bytes.Buffer所有方法都是指针接收者，所以必须用&bytes.Buffer{} - 不要在测试里用
interface{}(t).(MyInterface)断言来“验证”，那只是运行时行为，掩盖了编译期本可捕获的问题
嵌入结构体时，Child 能否调用 Parent 的指针方法
能调用，但能否满足接口，取决于你嵌入的是 Parent 还是 *Parent。
例如：type Child struct { Parent } —— 此时 Child 的方法集不包含 *Parent 的方法（因为 Parent 是值嵌入，其提升方法的接收者仍是 *Parent，而 Child 并不等价于 *Parent）；但 type Child struct { *Parent } 就可以，因为 *Parent 的方法被提升后，接收者类型仍为 *Parent，而 Child 包含一个 *Parent 字段，可寻址。
- 常见坑：嵌入
Parent后发现Child{}无法赋值给某接口，但&Child{}可以——问题不在Child，而在嵌入字段本身的方法集归属 - 统一建议：若嵌入的结构体本身用指针接收者实现关键接口（如
json.Marshaler），优先嵌入*Parent - 嵌入不改变原方法的接收者类型，只影响提升后方法在外部类型的可用性
什么时候必须用指针接收者，什么时候可以用值接收者
不是风格偏好，是语义和规则双重约束。两个硬性条件决定了你别无选择：
- 方法需要修改接收者字段（如
func (b *bytes.Buffer) Write(p []byte)）→ 必须用指针接收者，否则修改无效 - 结构体较大（例如含
[]byte、map、嵌套 struct 或 >16 字节）→ 指针接收者避免拷贝开销，标准库广泛采用此约定 - 若接口方法签名已定（如第三方库定义的
fmt.Stringer），且其实现方法用了指针接收者，那你实现时也必须用指针接收者，否则类型不满足接口 - 值接收者更“通用”：它让
T和*T都能实现同一接口，但仅适用于小、不可变、无状态的类型（如time.Time）
最容易被忽略的点：同一个结构体上混用值和指针接收者实现同一接口的不同方法，会导致部分方法在值类型上调用失败、部分在指针类型上才可用——这不是 bug，是方法集规则的必然结果，但会让调用方极难预测。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
