io.Pipe不能直接用于文件转换，因其无缓冲、无背压控制、一端阻塞即导致整链死锁；可靠方案需用带缓冲channel（如make(chan []byte, 16)）配合goroutine、os.Open、io.Copy等组合实现可控分块传输。
别用 io.Pipe 直接连文件读写——它没缓冲、不背压、一端卡住整条链就死锁。 真正能稳跑大文件的流式处理，得靠带缓冲的 chan []byte + 显式 goroutine 控制，再配 io.Copy 或 csv.Reader 这类标准流接口。
为什么 io.Pipe 不能直接接 os.File
io.Pipe 返回的 pr 和 pw 是内存里一对强绑定端点，没有内部缓冲区。你调 pw.Write()，它会一直阻塞，直到有 goroutine 在另一端调 pr.Read()；反过来也一样。常见错误是：
- 主线程开
io.Pipe()，然后同步调io.Copy(pw, srcFile)，但下游还没启 reader —— 写操作立刻卡死 - 写了数据后忘了
pw.Close()，下游pr.Read()永远等不到io.EOF，协程泄漏 - 把
pw当成bufio.Writer用，以为写进去就“发出去了”，实际只是在等被读
用 chan []byte 实现可控分块传输
这才是处理大文件（如 CSV、日志、归档流）的可靠路径：把文件按块读进内存，通过带缓冲 channel 中转，下游按需消费。关键控制点：
- 缓冲 channel 建议设为
make(chan []byte, 16)（约 64KB），太小易频繁阻塞，太大吃内存 - 每次
file.Read(buf)后必须检查n > 0才拷贝，避免传空 slice 或复用底层数组导致数据错乱 - 读 goroutine 结束前必须
defer close(ch)，否则下游range ch会永远挂住 - 别在 channel 里传未拷贝的
buf[:n]—— 多个消费者可能同时改同一块内存
如何安全接入 csv.Reader 或 gzip.Writer
流式处理不是“全量读完再塞给解析器”，而是让解析器直接从流中拉数据。比如接 CSV：
立即学习“go语言免费学习笔记（深入）”；
- 不要先用
io.Copy把整个文件写进bytes.Buffer，再拿csv.NewReader(buffer)—— 这等于放弃流式，内存爆表 - 正确做法：上游是
chan []byte→ 启 goroutine 把数据写入io.PipeWriter→csv.NewReader(pipeReader)直接消费 - 中间加压缩？用
gzip.NewWriter(outFile)作最终io.Writer，让io.Copy(gzipWriter, pr)自动背压，上游自然慢下来 - 要算哈希或日志？用
io.TeeReader(pr, hasher)，不是先读全再分发
错误传播与关闭顺序最容易被忽略
管道崩掉往往不是语法错，而是关闭时机不对：
-
pw.Close()必须在所有写操作完成后调，且只能调一次；之后再pw.Write()直接 panic -
pr不用手动Close()，它由pw.Close()触发自动关闭 - 上游突然断流（如网络中断）、下游写磁盘卡住（如磁盘满）、
io.Copy返回非nilerror —— 这时该关哪个 writer？是否要 cancel context？下游 reader 还有没有机会 clean exit？这些细节不会报编译错误，但高负载时会集体爆发
