方法值 t.Set 是闭包式函数，类型为 func(int)，接收者已固化；方法表达式 T.Set 是普通函数，类型为 func(*T, int)，需显式传接收者。二者类型、参数、调用方式均不同，混用将导致编译失败。
方法值 t.Set 和方法表达式 T.Set 根本不是同一种东西
它们类型不同、参数不同、调用方式也不同，混用会直接导致编译失败或行为诡异。别被名字骗了——t.Set 是一个闭包式函数值，T.Set 是一个带显式接收者的普通函数。
-
t.Set的类型是func(int)（假设原方法是func(t *T) Set(v int)），调用时直接传v，接收者t已“固化”在其中 -
T.Set的类型是func(*T, int)，必须手动传入接收者指针作为第一个参数，比如T.Set(&t, 42) - 用
reflect.TypeOf一试便知：reflect.TypeOf(t.Set)返回func(int)，而reflect.TypeOf(T.Set)返回func(*T, int) - 常见错误：把
T.Set当作可直接调用的函数传给回调（如time.AfterFunc(d, T.Set)）——编译报错：cannot use T.Set (type func(*T, int)) as type func()
什么时候该用方法值 t.Set？
当你需要把「某个实例的某个方法」当作普通函数来传递、存储或延迟执行时，就用方法值。它省去重复传接收者的麻烦，语义清晰。
- 典型场景：注册回调、塞进
map[string]func()、传给sort.SliceStable的比较函数、绑定到 HTTP handler - 示例：
handler := user.UpdateProfile; http.HandleFunc("/profile", handler)—— 这里user是具体实例，UpdateProfile是方法名，handler就是方法值 - 注意接收者类型：如果方法定义是
func(t T) Foo()（值接收者），那t.Foo绑定的是t的副本，内部修改不会影响原变量；要用指针接收者才能改状态 - 性能无额外开销：方法值不是运行时闭包，Go 编译器会做优化，本质就是个带隐式上下文的函数指针
什么时候非得用方法表达式 T.Set？
只有两种刚需场景：泛型约束需要显式方法签名，或你要动态决定接收者（比如从接口或 map 中取实例再调用）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 泛型中无法写
t.Set（因为t类型不确定），但可以写T.Set并约束T实现该方法，例如：func do[T interface{ Set(int) }](v T) { T.Set(&v, 100) } - 反射调用：你拿到一个
reflect.Value实例v，想调它的Set方法，得先用v.MethodByName("Set")，这背后实际走的就是方法表达式逻辑 - 反模式警告：别为了“看起来统一”而硬写
T.Set(&t, x)替代t.Set(x)—— 多余、啰嗦、易错（比如忘了取地址）
方法集和指针接收者是绕不开的坑
方法值和方法表达式是否可用，完全取决于「接收者类型」和「调用者的类型」是否匹配方法集规则。这是最常卡住人的地方。
立即学习“go语言免费学习笔记（深入）”；
- 如果方法是
func(t *T) M()（指针接收者），那么只有*T类型的值能产生方法值：var t T; t.M报错；pt := &t; pt.M才合法 - 同理，
T.Set方法表达式要求你传*T，不是T；传错会编译失败：cannot use t (type T) as type *T in argument to T.Set - 接口赋值也受此限制：一个
interface{ M() }变量，只能由*T赋值（若M是指针接收者），T赋值会静默失败（编译报错） - 容易忽略的点：结构体字段嵌入时，方法集继承也遵循同一套指针/值规则，别想当然认为“嵌入了就有”
