reflect.typeof(x).method(i) 返回的是类型方法描述而非可调用对象，func 字段需手动传入接收者才能调用；值/指针接收者方法集分离，私有方法不可见，接口实现判定与反射枚举无关。
reflect.TypeOf(x).Method(i) 返回的是类型方法描述，不是可调用对象
很多人误以为 reflect.Type.Method(i) 返回的 Func 字段可以直接调用，其实它只是未绑定接收者的函数值。直接 Call() 会 panic：“call of reflect.Value.Call on zero Value”。
这是因为 Func 是从类型层面提取的签名描述，不携带任何实例上下文。真正可调用的方法必须通过 reflect.Value 实例获取。
- 正确路径：先有结构体实例（如
&s），再用reflect.ValueOf(&s).MethodByName("Do") - 若硬要用
Type.Method(i).Func，必须手动构造参数切片，并显式把接收者作为第一个参数传入：append([]reflect.Value{receiver}, args...) - 接收者类型必须匹配：值接收者方法可用
reflect.ValueOf(s)或reflect.ValueOf(&s).Elem()；指针接收者方法必须用reflect.ValueOf(&s)，否则CanCall()返回 false
值类型与指针类型的方法集在反射中完全分离
reflect.TypeOf(MyStruct{}) 和 reflect.TypeOf(&MyStruct{}) 返回的 Type 对象不同，它们的 NumMethod() 结果也不同——前者只含值接收者方法，后者包含值+指针接收者方法。
这和 Go 接口实现规则一致：方法集是编译期静态确定的，反射只是如实呈现它。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 嵌入字段是否为指针，直接影响外层结构体能否“提升”其方法：只有
type Outer struct{ *Inner }才能获得*Inner的指针接收者方法 - 若结构体字段是
Inner（非指针），即使该字段有指针接收者方法，也无法被外层结构体提升调用 - 遍历方法时，
Method(i)的顺序不保证与源码一致，也不按字母排序，不能依赖索引做逻辑判断
私有方法无法通过反射获取或调用
Go 反射机制严格遵循封装原则：reflect.Type.Method(i) 和 reflect.Value.MethodByName() 都只返回首字母大写的导出方法。所有小写开头的方法在反射中完全不可见。
这不是限制，而是设计使然。试图绕过（比如用 unsafe 或字段偏移）既不稳定，又破坏包边界语义。
- 常见错误：对
func (s *T) doStuff()调用v.MethodByName("doStuff")，结果IsValid() == false - 如果需要反射调用，必须将方法名改为
DoStuff，或改用接口抽象行为（如定义Doer接口并让类型实现） - 反射不区分标准库方法和用户方法，
m.PkgPath == ""只表示导出，不代表“属于当前包”
接口实现判定与反射方法枚举不是一回事
一个类型是否实现某接口，由其方法集是否完整匹配接口方法签名决定；而反射枚举出的方法，只是该类型「当前可见」的导出方法集合。二者目标不同、依据不同。
例如：某接口要求 func (t *T) Read(p []byte) (n int, err error)，但 T 只实现了值接收者版本，则 reflect.TypeOf(T{}).NumMethod() 可能返回非零，但它仍不满足该接口。
- 反射看到的是“有哪些方法”，接口判定看的是“方法集是否覆盖接口全部签名”
-
reflect.Type.Implements()可用于运行时检查类型是否实现某接口，但它依赖的是类型本身的方法集，不是你手头那个具体值的可调用性 - 最易忽略的一点：接口变量中存储的值是不可寻址的，所以即使
t.M()在普通代码里能自动取址调用，存进接口后仍无法满足指针接收者接口要求
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
