io.Pipe适用于边读边写且不能全量加载内存的流式场景，如日志转发、大文件压缩上传、CSV流式HTTP响应；需调用CloseWithError避免读端阻塞，慎用os.ReadFile等全量读取方式以防OOM。
什么时候该用 io.Pipe 而不是直接读文件
当你的处理逻辑需要「边读边写」且中间不能全量加载进内存时，io.Pipe 是最轻量的流式协调工具。比如日志实时转发、大文件压缩上传、数据库导出 CSV 流式响应 HTTP 请求——这些场景下，你无法等文件完全读完再处理，也不能把整个文件塞进 []byte。
常见错误是误用 os.ReadFile 或 io.ReadAll 去处理 GB 级日志，结果 OOM；或者用 bufio.Scanner 读超长行（默认 64KB 限制），直接 panic。
-
io.Pipe适合生产者/消费者节奏不一致的场景，比如解密速度慢但网络上传快，它靠内部缓冲区（默认 4KB）自动阻塞协调 - 若两端处理速率接近且无格式解析需求，直接用
io.Copy+os.Open更省事 - 注意
io.PipeWriter.CloseWithError必须调用，否则读端会永远阻塞在 EOF 前
gzip.NewReader 配合 http.ResponseWriter 的典型漏点
Web 服务返回压缩流时，很多人只记得 w.Header().Set("Content-Encoding", "gzip")，却忽略底层 ResponseWriter 可能已被封装（如使用了 gin 或 echo 中间件），导致 gzip.Writer 写入失败或响应头被覆盖。
更隐蔽的问题是：未设置 Content-Length —— 流式压缩无法预知长度，必须用 chunked encoding，而某些老旧客户端或代理对此支持不佳。
- 务必检查
http.ResponseWriter是否实现了http.Hijacker或http.Flusher，否则gzip.Writer的 flush 行为可能无效 - 避免在
gzip.Writer之后再写 header，Go 的net/http会在第一次Write时冻结 header - 测试时用
curl -H "Accept-Encoding: gzip" -v http://localhost:8080/xxx看响应头和 body 是否真实压缩
处理 CSV/JSON Lines 文件时，encoding/csv 和 json.Decoder 的流式边界
encoding/csv.Reader 本质是流式，但默认按行缓存，遇到超长字段或缺失换行符会卡住；json.Decoder 支持逐个解码 JSON Lines（每行一个 JSON 对象），但对 malformed line 会直接返回 error 并中断整个流。
典型翻车现场：日志文件里某一行多了个逗号，csv.Reader.Read() 报 unexpected end of CSV input 后无法继续读下一行；或者 JSON Lines 里混入了空行，json.Decoder.Decode 直接 panic。
- 用
csv.NewReader时调用r.FieldsPerRecord = -1允许变长字段，
再手动截断过长行 - 处理 JSON Lines 推荐包装一层：用
bufio.Scanner按行读，再对每行用json.Unmarshal，出错仅跳过当前行 - 别依赖
csv.Reader的ReadAll方法——它会把所有记录加载进内存，失去流式意义
再手动截断过长行func streamJSONLines(r io.Reader, fn func(map[string]interface{}) error) error {
scanner := bufio.NewScanner(r)
for scanner.Scan() {
line := scanner.Bytes()
if len(line) == 0 {
continue
}
var v map[string]interface{}
if err := json.Unmarshal(line, &v); err != nil {
log.Printf("skip invalid JSON line: %v", err)
continue
}
if err := fn(v); err != nil {
return err
}
}
return scanner.Err()
}
为什么 io.MultiReader 不适合拼接动态生成的大文件
io.MultiReader 看似能无缝合并多个 io.Reader，但它的实现是顺序穷举——前一个 reader 返回 EOF 后才切换下一个。如果某个 reader 是从网络拉取或需复杂计算（比如从对象存储分块下载），一旦卡住，后续所有 reader 都无法开始，丧失并行性。
更关键的是：它不提供任何进度反馈或取消机制，调试时连卡在哪一环都难定位。
- 替代方案优先考虑
io.Pipe+ goroutine 分别写入，或用chan io.Reader配合io.MultiReader动态构造 - 若需限速或监控吞吐，必须自己封装
io.Reader实现Read方法，注入计数和 context.Done 检查 - 注意
io.MultiReader不会关闭其内部 readers，资源泄漏风险得自己兜底
io.Copy 的 error 处理分支里，而不是开头的 pipe 创建逻辑中。
