io.Pipe不能直接用于文件转换，因其无缓冲、无背压控制、一端阻塞即导致整链死锁；可靠方案需用带缓冲channel（如make(chan []byte, 16)）配合goroutine、os.Open、io.Copy等组合实现可控分块传输。
直接用 io.Pipe 做文件转换是危险的——它不自带缓冲、不处理背压、一端阻塞整条链。真要可靠做文件转换，得用带缓冲的 channel + 显式 goroutine 控制，再配合 os.Open / io.Copy / bufio.Scanner 等组合。
为什么不能直接用 io.Pipe 接文件读写
io.Pipe 返回的是 io.Reader 和 io.Writer，看起来像 Unix 管道，但它本质是内存里的单向同步通道：一端卡住，另一端就死锁。比如你用 io.Copy(w, file) 往 pipe 写，但下游还没开始读，w.Write 就会永远阻塞（无缓冲），整个流程挂住。
- 它没有容量概念，不是队列，不能“暂存”数据
- 错误传播弱：写端 panic 不会自动关读端，容易漏 recover
- 无法控制并发粒度，不适合分块处理大文件
用 chan []byte 实现可控分块传输
把文件切片读入内存 buffer，通过带缓冲 channel 中转，下游按需消费。这样能控速、可取消、易调试。
- 缓冲大小建议设为
make(chan []byte, 16)（约 16 × 4KB = 64KB），避免内存暴涨又不至于太小导致频繁阻塞 - 读端必须用
defer close(ch)，否则range ch永远等不到关闭信号 - 每次
read后检查n == 0 && err == nil表示 EOF，别只看err != nil - 不要在 channel 里传大 struct 或未拷贝的 slice 底层数组——多个 goroutine 可能同时改同一块内存
示例片段：
立即学习“go语言免费学习笔记（深入）”；
ch := make(chan []byte, 16)
go func() {
defer close(ch)
buf := make([]byte, 4096)
for {
n, err := file.Read(buf)
if n > 0 {
data := make([]byte, n) // 必须拷贝
copy(data, buf[:n])
ch <- data
}
if err == io.EOF {
break
}
if err != nil {
log.Printf("read error: %v", err)
break
}
}
}()多阶段转换时如何避免 goroutine 泄漏
每个处理阶段（如解码 → 过滤 → 编码）都该有独立 channel 和超时/取消控制。裸跑 go stage(in, out) 容易让 goroutine 卡在 channel 发送或接收上，尤其上游提前退出时。
- 所有阶段函数签名应含
ctx context.Context，并在select中监听ctx.Done() - 下游 stage 启动前，先用
go func() { defer close(out); ... }()包一层，确保即使 panic 也关 channel - 主流程用
sync.WaitGroup等待所有 stage goroutine 结束，而不是靠 channel 关闭顺序 - 如果某阶段需要“聚合后发”，别用无界 channel 存中间结果——改用
sync.Pool复用 buffer 或直接流式处理
实际文件转换中容易被忽略的边界点
真正上线的文件转换服务，90% 的问题不出在逻辑，而在这些细节：
-
os.Open打开的文件必须显式Close()，哪怕用了defer——goroutine panic 时 defer 不执行 - 写文件前确认目标目录存在：
os.MkdirAll(filepath.Dir(dst), 0755)，别依赖用户提前建好 - 二进制文件转换（如图片缩放）不能用
bufio.Scanner——它按行切分，会破坏原始字节流 - 若需原子写入（防写到一半崩溃），先写临时文件，再
os.Rename覆盖原文件
管道本身不解决可靠性，它只是并发编排的胶水。真正的健壮性来自对每个 I/O 节点的显式生命周期管理、错误分类处理和资源释放责任归属。
