不能直接把函数传进chan，因闭包捕获外部变量会导致竞态或访问已失效内存；应改用结构化消息通信或封装为结构体方法驱动。
为什么不能直接把函数传进 chan？
Go 的通道类型必须是具体、可比较的类型，而函数类型本身是可比较的（只要签名一致），但问题常出在「值传递」和「闭包捕获」上。比如你写 chan func() 是合法的，但若函数里引用了外部变量且没处理好生命周期，worker goroutine 可能读到已失效的栈或被 GC 回收的内存。
常见错误现象：panic: send on closed channel 或静默执行错误逻辑——其实不是通道问题，而是函数体里用了已释放的局部变量。
- 确保函数不依赖未逃逸的局部变量；必要时用参数显式传入所需数据
- 避免在循环中直接把匿名函数塞进通道：
for i := range jobs { ch —— 这里的 <code>i会被所有闭包共享，最终全变成最后一个值 - 更安全的做法是立即绑定：
ch 或封装成带参数的结构体
chan func() 和 chan func() error 性能差异在哪？
函数类型本身不参与内存分配，但接口类型（如 error）会触发接口值构造，带来微小开销。不过实际调度中，这点差异远小于 channel 操作、goroutine 创建和上下文切换的成本。
真正影响性能的是「是否阻塞等待返回结果」：如果 worker 必须同步返回 error，你就得配套用带缓冲的 chan error 或 sync.WaitGroup，否则容易卡死。
- 纯 fire-and-forget 场景（如日志写入、指标上报）用
chan func()足够 - 需要确认任务成败时，别让 worker 自己往另一个 channel 发 error，而应统一用
chan func() error并由调用方 select 等待 - 注意：返回
error的函数不能直接赋给func()类型变量，类型不兼容
如何防止 worker goroutine 泄漏？
最典型的泄漏场景是：主 goroutine 退出了，但 worker 还在从通道读、等不到关闭信号，一直阻塞在 上。
解决方案不是简单加 close(ch) —— 关闭后继续读会得到零值，func() 零值是 nil，一调就 panic。
- 用
chan struct{}作为 stop 信号，worker 中用select多路复用 - 或者改用
context.Context，worker 检查ctx.Done()，主流程调cancel() - 务必在启动 worker 后用
sync.WaitGroup计数，并在 worker 函数末尾defer wg.Done() - 别忘了在主流程里
go func() { wg.Wait(); close(doneCh) }()这类收尾逻辑
实际调度器里该用无缓冲还是有缓冲通道？
取决于你的吞吐模型。无缓冲通道（make(chan func(), 0)）意味着每次发送都会阻塞直到有 worker 接收，适合控制并发上限；有缓冲通道则允许快速攒一批任务再分发，但缓冲区大小设太大会吃内存，设太小又退化成无缓冲。
一个经验规则：缓冲大小 ≈ worker 数量 × 2～3，这样既避免频繁阻塞，又不会积压太多待执行函数。
- 如果任务生成速率波动大（如突发 HTTP 请求），优先选有缓冲通道 + 动态 worker 扩缩容
- 如果每个任务都很重（如图像处理），无缓冲更利于背压反馈，让生产者主动降速
- 切记：缓冲通道不能解决「worker 崩溃不重启」的问题，需配合 recover + 日志 + 重启逻辑
实际写的时候，最容易被忽略的是函数值的生命周期管理——它不像普通变量有明确作用域，而是在 goroutine 调度时才真正执行。一旦跨 goroutine 传递，就得当心它引用的所有东西是否还活着。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
