Go中func()不等于闭包，仅当捕获外层变量时才构成闭包；常见误区是混淆匿名函数与闭包，需警惕变量共享、延迟求值及内存泄漏问题。
Go 里写 func() 不等于就写了闭包；只有它捕获了外层变量，才构成闭包。别把所有匿名函数都当成闭包用，否则容易踩变量共享、延迟求值、内存泄漏的坑。
闭包不是“匿名函数”，而是“捕获了外部变量的函数”
很多人一看到 func() {} 就默认是闭包，其实不是。闭包的关键在于「变量捕获」——函数体里引用了定义它的外层作用域中的变量（比如局部变量、参数），且这个引用在函数返回后仍有效。
-
func() { fmt.Println("hello") }：没引用任何外部变量，只是普通匿名函数，不是闭包 -
count := 0; return func() int { count++; return count }：count被捕获，每次调用都操作同一个count，这才是闭包 - 闭包一旦形成，被捕获的变量生命周期会延长——哪怕外层函数已返回，这些变量也不会被 GC 回收
for 循环中直接创建闭包，i 值常被意外共享
这是 Go 新手最常踩的坑：在循环里创建多个闭包，却发现它们都打印出最后一个 i 值。
for i := 0; i < 3; i++ {
go func() {
fmt.Println(i) // 全部输出 3
}()
}
原因：i 是循环变量，整个循环共用一个内存地址；闭包捕获的是 &i，不是 i 的副本。解决办法只有两个：
立即学习“go语言免费学习笔记（深入）”；
- 显式传参：
go func(val int) { fmt.Println(val) }(i) - 在循环内重新声明变量：
for i := 0; i
别依赖编译器自动优化，Go 1.22 仍保持该行为，必须手动隔离。
闭包用于 Handler 中间件时，validPath 预编译要放在包级
Web 路由中常见用法：用闭包封装验证逻辑，避免每个 handler 重复写正则匹配。
var validPath = regexp.MustCompile("^/(edit|save|view)/([a-zA-Z0-9]+)$")
func makeHandler(fn func(http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
m := validPath.FindStringSubmatch(r.URL.Path)
if m == nil {
http.NotFound(w, r)
return
}
title := string(m[2])
fn(w, r, title) // 闭包捕获了 title，并透传给实际 handler
}
}
注意点：
-
regexp.MustCompile必须在包初始化阶段执行（如全局变量），不能放闭包里反复编译，否则性能暴跌 - 闭包在这里的作用是「提前解析 URL 并提取参数」，再把干净的
title传给业务函数，解耦验证与处理 - 如果把
validPath放进闭包内定义，每次请求都会重编译正则，regexp.Compile开销不小
defer + 闭包修改命名返回值，ret 修改发生在 return 后
这个组合很隐蔽但很有用，尤其在统一错误包装场景：
func saveData(data []byte) (err error) {
defer func() {
if err != nil {
err = fmt.Errorf("save failed: %w", err)
}
}()
// ... 实际写入逻辑
return os.WriteFile("data.txt", data, 0644)
}
关键点：
- 命名返回参数
err在return语句执行时已赋值，但还没真正返回；defer的闭包在此之后运行 - 闭包能修改这个已赋值但未传出的
err，实现错误增强，无需在每处return前手动 wrap - 闭包里不能用
return语句，否则会覆盖原返回值；只能修改命名返回变量本身
闭包真正的复杂点不在语法，而在变量生命周期和求值时机——它让代码看起来线性，实际执行顺序却分三层：定义、捕获、调用。漏掉任一环，结果就和直觉相反。
