Go中函数值是值类型但底层为指针，支持赋值传参和比较（仅同一函数或nil），闭包捕获变量地址而非值快照，循环中需避免共享循环变量。
函数值在 Go 中是值类型，但底层携带指针
Go 的函数变量确实是值类型，可以赋值、传参、比较（相同函数字面量或 nil），但它的“值”本质上是一个指向函数代码和闭包环境的结构体指针。你不能对函数变量做 &f 取地址（编译报错 cannot take the address of f），也不能用 unsafe.Sizeof(f) 看到它像普通 struct 那样可拆解——它被语言抽象封装了。
常见错误现象：if f == g { ... } 在多数情况下恒为 false，除非 f 和 g 是同一个函数字面量（或都为 nil），因为每次声明匿名函数都会生成新实例；闭包捕获变量后，即使函数签名相同，f != g 也几乎总是成立。
- 函数值支持直接比较，但仅用于判断是否为同一函数实体（含相同闭包绑定），不是逻辑等价
- 作为参数传递时，函数值按值拷贝，但拷贝的是内部指针，所以性能无额外开销
- 不能用
reflect.ValueOf(f).CanAddr()判断其是否可寻址——它本身不可寻址，这是语言设计决定的
闭包捕获变量的方式决定行为，不是“引用传递”也不是“值复制”
闭包不“复制”变量，也不“引用”原始变量，而是捕获变量的内存位置（即变量的地址）。如果捕获的是局部变量，Go 会自动将其分配到堆上（逃逸分析决定），确保闭包调用时该变量仍有效。
使用场景：需要延迟执行、回调、状态保持（如计数器、配置闭包）时，闭包比显式传参更简洁；但若误以为捕获的是值快照，就容易踩坑。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 循环中创建闭包时，若直接捕获循环变量（如
for i := range xs { go func() { println(i) }() }），所有闭包共享同一个i地址，最终可能全打印最后一个值 - 正确做法是显式传参：
go func(val int) { println(val) }(i)，或在循环内用新变量绑定：for i := range xs { i := i; go func() { println(i) }() } - 捕获指针变量（如
&x）和捕获普通变量（如x）效果不同：前者闭包看到的是指针指向的内容变化，后者看到的是变量值在闭包创建时刻之后的更新（因仍是同一地址）
函数类型比较与接口转换的兼容性边界
两个函数类型是否可相互赋值，取决于签名完全一致：参数个数、类型、顺序，返回值个数、类型、顺序，缺一不可。哪怕只是多一个命名返回值，或参数名不同，都不兼容。
性能影响很小，但类型系统严格导致常见错误：把 func(int) error 当成 func(int) (int, error) 传给期望后者的函数，编译直接失败；或者试图将函数赋给 interface{} 后再转回具体函数类型，会 panic（类型断言失败）。
- 函数类型不实现任何接口（包括空接口
interface{}）的“方法集”，但可以存入interface{}，只是取出来时必须用原类型断言 - 不能用
fmt.Printf("%p", f)打印函数地址——会报错；可用fmt.Printf("%v", f)得到类似0x456789的十六进制表示，但这只是调试用，不保证稳定或可比 - 跨包使用函数类型时，建议定义具名类型（如
type HandlerFunc func(http.ResponseWriter, *http.Request)），避免签名散落导致不一致
闭包逃逸与内存分配的实际表现
闭包是否导致变量逃逸，取决于它是否捕获了局部变量。哪怕只捕获一个 int，只要该变量被闭包引用，Go 编译器大概率把它挪到堆上——这不是优化问题，而是语义必需：栈帧在函数返回后就销毁了，而闭包可能在之后任意时间执行。
你可以用 go build -gcflags="-m" main.go 查看逃逸分析结果。典型输出如：main.go:12:6: &i escapes to heap，说明变量 i 因被闭包捕获而逃逸。
- 频繁创建小闭包（如在热循环里）会增加 GC 压力，尤其当捕获大结构体或切片时
- 若闭包不捕获任何外部变量（纯函数字面量），则不会引发逃逸，且可能被内联优化
- 用
sync.Pool缓存闭包本身意义不大——函数值本身不占多少内存，真正要优化的是它捕获的那些堆对象
最常被忽略的一点：闭包捕获的是变量的“绑定”，不是“快照”。哪怕变量后续被重新赋值，只要没超出作用域，闭包看到的就是最新值——这点和 JavaScript 不同，但和 Go 的指针模型完全一致。理解这一点，才能避开绝大多数闭包陷阱。
