方法表达式 TypeName.MethodName 是将类型的具体方法“抠出来”生成普通函数值，如 bytes.Buffer.Write 生成 func(bytes.Buffer, []byte) (int, error)；它不捕获实例、无状态，适合注册或反射预绑定。
方法表达式 TypeName.MethodName 是什么
它不是调用，而是把某个类型的具体方法“抠出来”，变成一个普通函数值。比如 *bytes.Buffer.Write 就是把 Write 方法绑定到 *bytes.Buffer 类型上，生成一个形如 func(*bytes.Buffer, []byte) (int, error) 的函数。
常见错误现象：写成 buf.Write（没加类型名）就报错 —— 这是方法值，不是方法表达式；或者误以为 bytes.Buffer.Write 能直接用，结果编译失败，因为非指针类型的方法不能被表达式引用（除非该方法接收者是值类型）。
- 只有显式写出
TypeName.MethodName才是方法表达式，obj.MethodName是方法值 - 接收者是值类型时，
TypeName.MethodName和*TypeName.MethodName都合法；但接收者是指针类型时，只能用*TypeName.MethodName - 方法表达式不捕获实例，所以它本身不带状态，适合做通用函数注册或反射前的预绑定
方法变量（方法值）obj.MethodName 怎么传参
这是最常用也最容易出错的点：方法值自动绑定了接收者，调用时不能再传接收者参数。比如 buf.Write 的类型是 func([]byte) (int, error)，不是 func(*bytes.Buffer, []byte) (int, error)。
使用场景：传给 http.HandlerFunc、塞进切片当回调、作为 goroutine 启动参数等。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 传参时别多传一个
buf，否则编译报错：too many arguments - 如果原方法接收者是指针，但你用的是值实例（如
var b bytes.Buffer; b.Write），Go 会自动取地址 —— 但前提是b是可寻址的；局部变量字面量（如bytes.Buffer{}）不可寻址，这时(bytes.Buffer{}).Write直接报错 - 方法值会延长接收者生命周期：若
buf是局部变量，而你把buf.Write保存到全局 map 里，buf就不会被 GC，可能引发内存泄漏
函数类型不匹配：为什么 func([]byte) (int, error) 不能赋给 func(io.Writer, []byte) (int, error)
这是典型类型系统误解。方法值和方法表达式生成的函数类型，由接收者是否包含在签名里决定。前者不含，后者含 —— 它们是完全不同的类型，无法互相赋值，哪怕逻辑一致。
错误现象：cannot use buf.Write (type func([]byte) (int, error)) as type func(io.Writer, []byte) (int, error)。
-
buf.Write是方法值 → 类型为func([]byte) (int, error) -
(*bytes.Buffer).Write是方法表达式 → 类型为func(*bytes.Buffer, []byte) (int, error) - 两者都跟
io.WriteString或自定义的双参函数不兼容，必须显式包装：func(w io.Writer, b []byte) (int, error) { return w.Write(b) } - 别指望类型推导能“自动适配”——Go 不做隐式转换，函数类型精确匹配
性能与逃逸：方法值捕获接收者时发生了什么
方法值本质是一个闭包，内部持有接收者引用。这会影响逃逸分析结果，尤其当方法值逃逸到堆上时，接收者也会一起逃逸。
比如把 buf.Write 存进全局 slice，buf 就从栈移到堆；若 buf 很大（如含 KB 级缓冲区），代价明显。
- 用
go tool compile -gcflags="-m"可观察是否逃逸；常见提示：... escapes to heap - 方法表达式（如
(*bytes.Buffer).Write）不捕获实例，因此无此问题，但调用时必须手动传接收者 - 高频场景（如网络连接处理循环）中，反复构造方法值可能增加 GC 压力，此时优先考虑传参方式或复用函数变量
