u.Method 是方法值（func(...)），T.Method 是方法表达式（func(T,...)），前者固化接收者可直接调用，后者需显式传入接收者；Go 类型系统严格区分二者，不隐式转换。
Go 里把 u.Method 和 T.Method 当成同一种东西用，十有八九会编译失败——不是语法错，是类型系统在拦你。
为什么 u.Method 能直接传给 func()，而 T.Method 不行？
因为它们根本不是同一类东西：u.Method 是方法值（Method Value），类型是 func(...)；T.Method 是方法表达式（Method Expression），类型是 func(T, ...) 或 func(*T, ...)。
前者已把接收者 u 固化进函数闭包，调用时无需再传；后者还留着接收者当第一个显式参数，必须手动塞进去。
-
reflect.TypeOf(u.Update)返回func(string) -
reflect.TypeOf(User.Update)返回func(*User, string) - Go 不做隐式补参，也不自动转换类型——写错就是报错，不妥协
什么时候该用 u.Method（方法值）？
当你已经有具体实例，且想把它某个方法当普通函数来传递、存储或延迟调用时，就用方法值。
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
- 注册 HTTP 处理器：
http.HandleFunc("/save", user.Save) - 塞进函数切片：
handlers := []func(){user.Load, user.Validate} - 绑定定时器：
time.AfterFunc(5*time.Second, user.Logout) - 注意接收者类型：如果
user.Save定义为func(u User) Save()（值接收者），内部改字段不会影响原user；要改状态，得用指针接收者
什么时候必须用 T.Method（方法表达式）？
当你需要泛化调用、反射、或构造可复用的高阶逻辑时，方法表达式更合适——它暴露了接收者参数，便于动态传入不同实例。
- 配合
reflect调用：meth := reflect.ValueOf(&u).MethodByName("Update")，底层依赖的就是方法表达式语义 - 写通用工具函数，比如封装一个带重试的调用器：
retry(func() { u.Do() })可以，但retry(u.Do)行不通——除非你明确知道u.Do是方法值 - 定义接口适配层时，有时需显式解耦接收者，比如
func(fn func(*T))接收的是方法表达式签名
最容易被忽略的一点：方法值在赋值瞬间就拷贝了接收者（哪怕是指针，也是拷贝指针值），后续对原变量的修改不影响已绑定的方法值；而方法表达式每次调用都用当前传入的接收者——这个行为差异，在状态敏感的场景里会直接导致 bug。
