myStruct 不能调用 myStruct 上的方法，因为值类型变量的方法集仅包含值接收者方法，而指针接收者方法只属于 myStruct 的方法集；接口实现要求实参类型的方法集完全匹配接口方法签名。
为什么 myStruct 不能调用定义在 *myStruct 上的方法？
Go 的方法集规则决定了“谁有资格调用谁”——不是看类型长得像，而是看接收者类型和实参类型是否匹配。值类型变量的方法集只包含接收者为值类型（func (s myStruct) Foo()）的方法；指针变量的方法集则同时包含值接收者和指针接收者（func (s *myStruct) Bar()）的方法。
常见错误现象：cannot use myVar (type myStruct) as type interface{Bar()} in argument to call: myStruct does not implement interface{Bar()} (Bar method has pointer receiver)。这说明接口要求实现 Bar，但你的变量是值类型，而 Bar 只在 *myStruct 方法集中。
- 如果想让值变量也能满足含指针接收者方法的接口，必须传地址：
someFunc(&myVar) - 如果方法内部要修改字段，接收者必须是
*T；若只是读取，T或*T都行，但建议统一用*T避免后续扩展麻烦 - 嵌入字段时同理：嵌入
T不会提升其指针方法到外层；嵌入*T才能“带出”指针方法集
接口断言失败却没报错？检查方法集是否真匹配
接口断言（v, ok := x.(MyInterface)）成功与否，取决于动态值的实际类型是否实现了该接口——而“实现”的判定依据正是方法集。容易被忽略的是：即使两个类型都有同名方法，只要接收者类型不一致，就不算实现。
使用场景：把结构体存进 interface{} 后再转成某个接口；或用泛型约束时类型参数推导失败。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
var s myStruct; var i interface{} = s; _, ok := i.(Reader)→ 若Read是func (*myStruct) Read(...)，则ok为false - 用
fmt.Printf("%v", s)看实际类型：输出是{...}（值）还是&{...}（指针），能快速判断方法集范围 - 别依赖 IDE 自动补全来判断能否调用——它可能只检查语法，不校验方法集归属
切片、map、channel 的方法集为什么总是空的？
因为它们是引用类型，但 Go 规定：内置类型（[]T、map[K]V、chan T、func、interface{}）不允许绑定方法。你写不出 func (s []int) Len() int 这样的代码，编译直接报错：invalid receiver type []int ([]int is not a defined type)。
性能影响：这不是权衡，是硬性限制。想封装行为，必须用自定义类型包裹：
- 正确：
type IntSlice []int; func (s IntSlice) Len() int { return len(s) } - 错误：
func (s []int) Len() int { ... }→ 编译失败 - 注意：
type MyMap map[string]int合法，但map[string]int本身永远无法拥有方法
为什么给 nil 指针调用方法有时 panic，有时却正常？
关键看方法体内是否解引用了接收者。Go 允许对 nil 指针调用方法——只要方法没碰 *s 字段或方法。这是有意设计，用于实现类似“零值可用”的模式（如 sync.Mutex 的 Lock()）。
容易踩的坑：以为 nil 一定 panic，结果测试漏掉空指针路径；或相反，以为安全就放任不管，导致运行时崩溃。
- 安全示例：
func (s *myStruct) IsEmpty() bool { return s == nil || s.data == nil }→ 可接受nil - 危险示例：
func (s *myStruct) PrintName() { fmt.Println(s.name) }→s为nil时 panic - 检查方式：在方法开头加
if s == nil { return }或明确文档说明是否支持nil
