p.Method能直接传给func()参数是因为它是接收者已固化的方法值，类型为func(...)；T.Method是需显式传接收者的方法表达式，类型为func(T, ...)，二者类型不匹配导致编译失败。
为什么 p.Method 能直接传给 func() 类型参数，而 T.Method 不能？
因为二者类型完全不同：p.Method 是方法值（Method Value），类型是 func(...)，接收者已固化；T.Method 是方法表达式（Method Expression），类型是 func(*T, ...) 或 func(T, ...)，必须显式传接收者。
常见错误现象：把 User.Update 直接传给 time.AfterFunc(d, User.Update)，编译报错 cannot use User.Update (type func(*User, string)) as type func() —— 这不是语法错，是类型不匹配。
-
reflect.TypeOf(p.Method)返回func(string)（假设原方法签名为func(u *User) Update(name string)） -
reflect.TypeOf(User.Update)返回func(*User, string) - 函数签名不一致，Go 不做隐式转换，也不会自动补第一个参数
什么时候该用 p.Method（方法值）？
当你有具体实例，且想把它某个方法当作普通函数来传递、存储或延迟调用时，就用方法值。它语义清晰、调用简洁、无额外开销。
典型使用场景：
- 注册回调：
http.HandleFunc("/save", user.Save) - 塞进函数切片：
handlers := []func(){ user.Load, user.Validate, user.Commit } - 传给泛型工具函数（如
sort.SliceStable(items, user.Less)） - 绑定到定时器：
time.AfterFunc(5*time.Second, user.Logout)
注意接收者类型影响行为：user.Save 若定义为 func(u User) Save()（值接收者），则内部修改 u 字段不会反映到原 user 变量上；要用指针接收者才能改状态。
什么时候必须用 T.Method（方法表达式）？
只有两类刚需场景需要方法表达式：泛型约束中需显式方法签名，或运行时动态决定接收者。
例如泛型函数要求类型实现某方法，但你不能写 t.Foo（因为 t 类型不确定），只能用 T.Foo 并约束 T：
func do[T interface{ Foo(int) }](v T) {
T.Foo(&v, 42) // 注意：这里 &v 是因 Foo 定义为指针接收者
}
另一个典型是反射调用：v.MethodByName("Foo").Call([]reflect.Value{...}) 底层走的就是方法表达式逻辑。
反模式警告：别在已有实例时硬写 User.Update(&user, "new") 替代 user.Update("new") —— 多余、易漏取地址、破坏可读性。
方法集规则如何决定 p.Method 是否可用？
能否写出 p.Method，不取决于 p 是值还是指针，而取决于「方法集」是否包含该方法 —— 即该方法的接收者类型是否与 p 的类型兼容。
- 若方法定义为
func(t *T) M()（指针接收者），则只有*T实例能形成方法值；T值实例调用t.M()是编译器自动取地址，但t.M本身不可用（会报cannot call pointer method on t） - 若方法定义为
func(t T) M()（值接收者），则T和*T都能形成方法值，但*T版本实际是先解引用再调用，内部操作的是副本
最容易被忽略的一点：方法值一旦生成，就固化了接收者当时的值或地址 —— 如果之后 p 被重新赋值或其字段被修改，p.Method 已绑定的上下文不会自动更新。
