Go中不能直接通过chan func()安全传递带闭包的函数值，因其可能隐式引用共享变量导致竞态；应改用channel传结构化消息并由固定goroutine执行，或封装为结构体方法驱动。
Go 里不能直接把函数值（尤其是带闭包的）通过 chan func() 安全传递并执行，这不是设计初衷，也极易出错。真正安全的做法是：用 channel 传数据，让固定 goroutine 执行函数逻辑；或把函数封装成结构体方法 + channel 消息驱动。
为什么不能直接用 chan func() 传函数
函数值本身是可复制的，但一旦它捕获了外部变量（即形成闭包），就可能隐式引用堆上对象或局部变量。多个 goroutine 并发调用同一闭包时，若这些变量被共享且无同步保护，就会触发 fatal error: concurrent map writes 或读写随机内存 —— 这类 bug 很难复现，调试成本极高。
- Go 不保证函数值跨 goroutine 调用时的内存可见性，尤其涉及指针、map、slice 等引用类型
-
func()类型通道无法静态约束参数和返回值，接收方不知道该传什么、怎么调、是否要等结果 - 发送方关闭 channel 后，接收方仍可能拿到已失效的闭包（比如引用了已退出作用域的栈变量）
chan struct{ f func(); args []interface{} } 是危险陷阱
有人试图用结构体包装函数和参数来“模拟回调”，但这只是把问题藏得更深：args 中若含指针或 map，依然会引发竞态；f 若在不同 goroutine 中多次调用，闭包环境早已不一致。
- 不要用
[]interface{}做泛型参数 —— 类型擦除后无法做类型安全检查，运行时 panic 风险高 - 即使加了 mutex，也无法解决闭包捕获变量的生命周期错配问题
- 这种模式本质是把 Go 的并发模型往“回调地狱”方向拉，违背 “Don’t communicate by sharing memory” 原则
正确做法：用 channel 传消息，由专用 goroutine 执行函数逻辑
把函数逻辑固化在某个长期存活的 goroutine 内部，只通过 channel 收发结构化请求和响应。这样闭包环境稳定、状态可控、错误可捕获。
立即学习“go语言免费学习笔记（深入）”；
- 定义请求结构体，字段为函数所需输入（值类型优先，避免传指针）：
type TaskReq struct { ID int; Data string } - 启动一个 worker goroutine，循环
select读取chan TaskReq，内部调用确定的函数（如processTask(req)） - 若需返回结果，配一个带缓冲的
chan TaskResp，worker 处理完后发回；或用带超时的select防止阻塞 - 关键点：所有闭包变量都在 worker goroutine 启动前初始化完毕，后续只读，不修改
更推荐：把函数转成结构体方法 + channel 驱动
将行为和状态绑定到 struct 上，channel 只负责触发动作。既清晰又利于测试，还能自然支持 context 取消和资源清理。
- 定义类型：
type Processor struct { mu sync.RWMutex; cache map[string]int } - 方法封装逻辑：
func (p *Processor) Handle(req TaskReq) TaskResp { p.mu.RLock(); defer p.mu.RUnlock(); return ... } - worker goroutine 持有
*Processor实例，收到 channel 消息后调用其方法 —— 闭包问题彻底消失 - 启动时传入初始化好的实例，而不是临时构造闭包；生命周期与 worker 一致，无悬空引用风险
真正容易被忽略的不是语法怎么写，而是闭包捕获的变量是否在多个 goroutine 间被无意共享。哪怕只有一行 data := &sharedMap 被传进函数，只要这个函数被多个 goroutine 并发执行，就大概率出问题。安全边界不在 channel 类型，而在变量作用域和所有权归属。
