for range 遍历 channel 仅在显式关闭后退出，否则永久阻塞；未关闭会导致死锁、goroutine 泄漏；发送方须用 sync.waitgroup 确保全部数据发完后由唯一协程调用 close()。
为什么直接用 chan []byte 做文件块流水线容易卡死
因为没控制缓冲区大小，生产者写太快、消费者处理太慢时，通道会阻塞整个 goroutine 链。尤其读大文件时，read 调用可能被挂起，下游还没消费，上游就停了。
- 默认无缓冲通道（
make(chan []byte)）必须“一写一读”，完全串行，失去流水线意义 - 缓冲通道设太大（比如
make(chan []byte, 1000)）会吃光内存，尤其块大小为 1MB 时，1000 个就是 1GB - 不显式关闭通道，
range会永远等待，goroutine 泄漏
怎么设计三层流水线：读块 → 处理 → 写出
每层之间用带缓冲的通道衔接，缓冲大小取 2–4，够掩盖 I/O 延迟又不爆内存；所有通道都由最上游负责关闭，并用 sync.WaitGroup 确保下游收完再退出。
-
readChunksgoroutine 从*os.File每次Read8192 字节到[]byte，填满就发到inCh，读完后close(inCh) -
processChunk从inCh收数据，做哈希或解密等 CPU 工作，结果发到outCh -
writeChunk从outCh收数据，调用file.Write写出，收到close后退出
inCh := make(chan []byte, 3) outCh := make(chan []byte, 3) go readChunks(f, inCh) go processChunk(inCh, outCh) go writeChunk(outCh, outF)
range 遍历通道时为什么不能省略 defer close() 的位置
必须在发送方 goroutine 里、循环结束后立即 close(ch)，否则接收方 range ch 永远等不到 EOF，主 goroutine 可能提前退出，导致后台 goroutine 没机会跑完。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 错误写法：
close(ch)放在main()末尾 —— 此时range还卡着，close已失效 - 正确写法：在
readChunks的for循环外加close(inCh)，确保所有块发完才关 - 接收端别用
for { select { case x := ，除非手动检查 <code>ok；range更安全
大文件下如何避免内存碎片和 GC 压力
反复 make([]byte, size) 分配小块，会触发频繁 GC；改用固定缓冲池复用内存更稳。
- 用
sync.Pool管理[]byte，例如var bufPool = sync.Pool{New: func() any { return make([]byte, 8192) }} - 每次从池取：
buf := bufPool.Get().([]byte)；用完归还：bufPool.Put(buf) - 注意：归还前别保留对
buf的引用，否则池里对象无法被复用 - 如果处理逻辑需扩容（如 base64 编码后变长），仍要
make新切片，但只在必要时
流水线不是越多 stage 越好，三个阶段（读/算/写）已覆盖绝大多数瓶颈点；加 stage 前先 profile，看 CPU 和 I/O 哪边拖后腿。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
