Go中传函数作参数需显式声明func类型，如type ProcessFunc func(string) (int, error)，匿名函数须严格匹配目标签名，闭包注意变量捕获和内存泄漏，复杂逻辑应转向struct封装。
Go 里怎么把函数当参数传？别漏掉类型声明
Go 不是函数式语言，但支持一等函数——函数可以赋值给变量、作为参数传入、从函数返回。关键在于：func 类型必须显式声明，不能省略参数和返回值类型。
常见错误是写成 func() {} 直接传参，结果编译报错 cannot use ... as type func() in argument——因为 Go 要求类型完全匹配，哪怕只差一个 error 返回值也不行。
- 传参前先定义类型更清晰：
type ProcessFunc func(string) (int, error) - 匿名函数传参时，必须和目标形参类型严格一致：
doSomething(func(s string) int { return len(s) })，前提是doSomething的参数类型是func(string) int - 注意闭包捕获变量的生命周期：若返回的函数引用了局部变量，该变量不会被提前回收，但要小心循环中重复捕获同一变量（比如
for _, v := range xs { fns = append(fns, func() { println(v) }) }最终所有闭包都打印最后一个v）
返回函数时，如何避免内存泄漏和状态混乱
返回函数本质是返回一个闭包，它携带了定义时的词法环境。这很强大，但也容易埋雷。
典型场景是工厂函数：func NewCounter(start int) func() int。每次调用 NewCounter 都应返回独立的状态，但如果误用全局变量或共享指针，多个返回函数会互相干扰。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 优先在闭包内创建新变量，而非引用外部可变状态：
func() int { count := start; return func() int { count++; return count } }()是错的写法（语法非法），正确是return func() int { start++; return start }——但这样就共享了start；更安全的是用结构体封装状态 - 如果闭包捕获了大对象（如 *http.Client、大型 map），而返回的函数长期存活，会导致该对象无法 GC；必要时显式置空引用
- 不要在 HTTP handler 中直接返回闭包函数并复用，goroutine 局部变量可能被并发访问，需加锁或改用 channel 协作
函数类型别名 vs struct 封装：什么时候该放弃函数式表达
Go 的函数类型适合简单、无状态、一次性的行为抽象。一旦涉及配置、生命周期、多方法协作，硬套函数就会反模式。
比如实现重试逻辑：func WithRetry(fn func() error, max int) func() error 看似函数式，但无法暴露重试间隔、指数退避、错误过滤等控制点，后续扩展只能不断加参数，类型签名爆炸。
- 当函数需要「配置」或「状态」时，立刻转向
struct+ 方法：type Retrier struct { Max int; Backoff func(int) time.Duration }，再提供Do(fn func() error) error - 函数类型别名（
type Handler func(http.ResponseWriter, *http.Request)）适合标准接口统一，但若需中间件链、日志、熔断，就得升级为type Handler interface { ServeHTTP(http.ResponseWriter, *http.Request) } - 工具函数（如
Map,Filter）可保留函数式风格，但注意切片操作本身是值拷贝，大 slice 传参会引发额外内存分配
性能敏感场景下，函数调用开销与逃逸分析的取舍
Go 中函数调用本身开销极小（几纳秒），真正影响性能的是闭包带来的堆分配和间接调用（interface{} 包装或 reflect.Call）。
用 go tool compile -gcflags="-m" 检查，若看到 ... escapes to heap，说明闭包捕获的变量被分配到堆上，尤其在高频循环中会放大 GC 压力。
- 避免在 hot path 上构造闭包：把预定义函数变量提到包级或方法外，复用而非反复生成
- 能用普通 for 循环替代
ForEach(slice, func(x T) { ... })就别用——后者不仅多一次函数调用，还让x更容易逃逸 - 如果函数参数是接口类型（如
io.Reader），而你传的是函数包装的func() (b []byte, err error)实现，那每次调用都会触发接口动态派发，比直接调用函数慢 2–3 倍
函数式不是银弹。Go 的设计哲学是“明确优于隐含”，过度封装函数类型会让调用方难以看清数据流和所有权边界。真正该纠结的不是“能不能函数式”，而是“这个抽象是否让错误更难发现、调试更难定位、性能更不可控”。
