t.Method能直接传参而T.Method编译失败，因为t.Method是方法值（类型如func(int)），接收者已固化；T.Method是方法表达式（类型如func(*T, int)），需显式传接收者，二者函数签名不兼容，Go拒绝隐式转换。
为什么 t.Method 能直接传参，而 T.Method 会编译失败
因为 t.Method 是方法值（Method Value），类型是纯函数类型，比如 func(int)；T.Method 是方法表达式（Method Expression），类型含显式接收者，比如 func(*T, int)。二者签名不兼容，强行传给期望 func(int) 的参数时，Go 直接报错：cannot use T.Method (type func(*T, int)) as type func(int)。
用 reflect.TypeOf 一眼可辨：
reflect.TypeOf(t.Save) // 输出：func() reflect.TypeOf(User.Save) // 输出：func(*User)
常见误用场景：
- 把未初始化的指针（如
var u *User）的u.Save当作方法值传——实际生成的是nil指针调用，运行时 panic - 对结构体字面量取方法值，如
user{}.Save—— 因不可寻址，编译失败 - 在 goroutine 中延迟调用方法值，但接收者是栈上局部变量且未逃逸——调用时行为未定义
t.Method 绑定的是副本还是地址，取决于接收者类型
值接收者（func(t T) Foo()）的方法值，每次调用都操作 t 的副本；指针接收者（func(t *T) Bar()）则绑定 &t，修改直接影响原结构体。
立即学习“go语言免费学习笔记（深入）”；
这直接影响状态一致性：
- 若方法需更新字段（如
user.IncLoginCount()），必须用指针接收者，否则计数不会生效 - 若结构体很大（含
[]byte、map[string]int等），值接收者方法值每次调用都会复制整块数据，CPU 和内存开销陡增 - 模板 FuncMap 中注册
o.Render时，o必须是指针，否则每次执行都拷贝整个渲染上下文
哪些地方最常用 t.Method，又容易踩什么坑
方法值的核心价值是「绑定实例 + 简化调用」，高频使用场景明确：
- 注册回调：
time.AfterFunc(time.Second, user.Save)——user必须已初始化且生命周期覆盖回调执行期 - HTTP handler：
http.HandleFunc("/logout", auth.Logout)——auth不能是局部临时变量 - 排序比较：
sort.SliceStable(items, item.LessThan)——item必须可寻址（不能是items[i]的只读副本） - 塞进 map：
handlers["save"] = db.SaveRecord—— 若db后续被重置或回收，调用时 panic
最容易被忽略的一点：方法值不是闭包，不捕获作用域变量，但它依赖接收者存活。如果把绑定局部变量地址的方法值传给 goroutine 延迟执行，而该变量已出作用域，结果不可预测——这不是 bug，是语言设计使然。
