方法表达式(T).Method的类型签名必须与接收者类型完全一致，包括指针与否；它将方法泛化为普通函数，接收者变为首参数，用于泛型、反射及回调场景，需显式传入接收者。
方法表达式 (T).Method 的类型签名必须匹配接收者类型
方法表达式不是“取方法地址”，而是把方法泛化成普通函数，接收者变成第一个显式参数。写成 (T).Method 时，T 必须和方法定义里的接收者类型完全一致——包括是否为指针。
- 如果方法是
func (s *Summable) Add(n int) int，那必须用(*Summable).Add，写成(Summable).Add会编译失败 - 错误信息通常是：
cannot use (Summable).Add (value of type func(Summable, int) int) as type func(*Summable, int) int - 类型不匹配时，
reflect.TypeOf((T).Method)显示的函数签名会暴露问题，比如返回func(main.T, int)但你实际需要func(*main.T, int) - 结构体嵌入时尤其容易踩坑：嵌入字段的方法若用指针接收者，外层类型调用时也得用指针类型构造方法表达式
传给回调或高阶函数时，(T).Method 需手动补接收者参数
方法表达式生成的是“带接收者参数”的函数，不能直接塞进只接受 func() 或 func(int) 的接口里。常见于 time.AfterFunc、sort.SliceStable 等场景。
-
time.AfterFunc(2*time.Second, (*User).Update)❌ 编译失败：类型不匹配，期望func()，得到func(*User) - 正确写法是包装一层：
time.AfterFunc(2*time.Second, func() { u := &User{}; u.Update() })，或改用方法值u.Update - 若必须用方法表达式（比如泛型约束中），需确保目标函数签名能容纳接收者参数，例如：
func do[T any](f func(T, int)) { f(t, 42) } - 反射调用时，
v.MethodByName("Update").Call([]reflect.Value{reflect.ValueOf(u)})底层走的就是方法表达式逻辑，首参必须是接收者
方法表达式在泛型中是唯一可行的“方法引用”方式
泛型函数无法持有具体实例，所以不能用方法值 t.Method；只能靠方法表达式 T.Method + 类型约束来抽象行为。
- 定义约束：
type Updater interface { Update(int) }，然后写func process[T Updater](t T) { t.Update(100) }—— 这是推荐做法 - 若需把方法本身作为参数传递（比如注册到 map 中统一调度），就得用方法表达式：
registry["update"] = (*User).Update，调用时f(u, 100) - 注意：泛型里不能写
t.Update，因为t是类型变量，不是具体值；T.Update也不合法（T是类型名，不是接收者类型）；真正可用的是(T).Update，前提是T满足约束且接收者类型明确 - 性能无额外开销：方法表达式在编译期解析，生成的代码和手写函数调用等价，不会引入运行时闭包
值接收者 vs 指针接收者：方法表达式会暴露拷贝语义
方法表达式不会改变方法本身的接收者语义。如果原方法用值接收者，(T).Method 调用时仍会复制接收者；用指针接收者，才真正操作原值。
立即学习“go语言免费学习笔记（深入）”；
-
func (s Summable) Mutate() { s = 999 }→(Summable).Mutate(s)执行后s不变，因为传入的是副本 -
func (s *Summable) Mutate() { *s = 999 }→(*Summable).Mutate(&s)才会修改原变量 - 调试时用
fmt.Printf("%p", &s)对比方法内&s地址，能快速验证是否用了指针接收者 - 除非方法纯读取且结构体极小（如
type ID string），否则一律用指针接收者，避免状态不一致
reflect.TypeOf 看一眼类型签名，比猜更可靠。 
