Python中不存在“for range in”语法，正确写法是“for i in range(…)”，常见错误包括漏冒号、缩进错误、range参数顺序不当（如start≥stop且step为正）或误在for循环体内修改循环变量i。
为什么不能直接用 for range in 后就返回
常见错误是写一个过滤器函数，里面直接 for s := range in { out ，然后函数就结束了。这会导致：上游没 close(in) 时，range 永远卡住；即使上游关了，out 也没被关闭，下游 range out 会永远等下去。真正安全的做法是把整个循环包进 goroutine，并用 defer close(out) —— 关闭动作必须绑定在该 goroutine 退出时。
make(chan T, N) 的缓冲大小怎么选
零缓冲 channel（make(chan int)）要求收发双方严格同步，一端阻塞就整条 pipeline 卡死；过大缓冲（比如 make(chan string, 100000)）又可能吃光内存，尤其处理大文件或高吞吐日志流时。实际建议：
- 纯顺序单 worker 阶段：缓冲 1–16 足够，例如
make(chan []byte, 8) - 扇出并行阶段（如 4 个 goroutine 读同一
in）：输入 channel 建议带缓冲，避免生产者因所有 worker 都忙而阻塞 - IO 密集型阶段（如 gzip 写入）：缓冲可稍大（32–128），掩盖 syscall 延迟
多个输入合并时，别手动 close 汇聚后的 channel
当需要 fan-in（比如 3 个 worker 同时往一个 out 写），常见错误是在每个 worker 里都 close(out) —— 第二次 close 就 panic：close of closed channel。正确做法是用 errgroup.Group 等待全部 worker 结束，再由主 goroutine 统一 close(out)。如果不用 errgroup，至少得用计数器 + sync.WaitGroup，确保仅一次关闭。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
什么时候不该用 channel 管道，而该用函数组合
管道模式不是银弹。如果你只是对几行字符串做 strings.ToUpper → strings.TrimSpace → strings.Split，直接链式调用更轻量、无 goroutine 开销、无 channel 管理负担。只有当下列任一条件成立时，才值得上 channel 管道：
- 数据源是流式的（如
bufio.Scanner读日志文件） - 某个阶段耗时波动大，需并发摊平延迟（如调用外部 API）
- 需要背压控制（上游不能比下游快太多）
- 各阶段生命周期不同（比如某阶段要长期监听信号再触发）
最易被忽略的一点：管道里每个 close(out) 都得和它对应的 for range in 在同一个 goroutine 里结束——跨 goroutine 关闭是 runtime panic 的温床，调试时往往只看到 “send on closed channel”，却找不到谁关早了、谁关多了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
