io.Pipe在图片流滤镜链中易卡死，因其无缓冲且写端阻塞于未消费的读端；多级处理中任一环节延迟或错误即导致整条流水线停摆，须改用bytes.Buffer暂存、显式Close写端、分块处理并为每层IO加context超时。
为什么 io.Pipe 在图片流滤镜链里容易卡死
因为默认不带缓冲，写端没被读端消费时会直接阻塞 goroutine。尤其在多级滤镜（比如缩放 → 水印 → 格式转换）中，中间某一级处理慢或出错，上游就会挂住，整个流水线停摆。
- 别用
io.Pipe()直接连 3 级以上image/jpeg.Decode或jpeg.Encode—— 它们不是流式友好的，会尝试读满整个输入 - 改用
bytes.Buffer做中间暂存，或给io.Pipe包一层带超时的io.LimitReader - 每级滤镜必须显式调用
Close()写端，否则读端永远等不到 EOF
怎么让 image/png.Decode 和 jpeg.Encode 在管道里真正流式跑起来
它们本身不支持“边读边解/边编”，但可以靠分块 + 缓冲绕过去。核心是避免一次性加载整张图到内存，而是用 image.DecodeConfig 先探尺寸，再按需裁剪/缩放。
- 先用
image.DecodeConfig读头信息，拿到Width/Height，决定是否跳过后续 decode - 对大图做缩放，优先用
golang.org/x/image/draw的Draw+SubImage，别全量 decode 后再 resize -
jpeg.Encode必须传入带缓冲的bufio.Writer，否则每次 write 都 syscall，吞吐暴跌
context.WithTimeout 必须加在哪几层
不是只加在最外层请求上下文上。图片流处理中，每个 IO 操作都可能卡住：HTTP body 读取、管道读写、编码器 flush。漏掉任意一层，就等于留了 hang 通道。
- HTTP handler 里用
ctx, cancel := context.WithTimeout(r.Context(), 10*time.Second) - 每个
io.Copy调用前，包一层http.MaxBytesReader或自定义io.LimitedReader - 如果用了第三方库（如
github.com/disintegration/imaging），检查它是否接受context.Context；不支持就自己起 goroutine + select 监听 done
Go 1.22+ 的 io.Stream 还不能直接用
目前没有 io.Stream 这个类型，那是社区误传。Go 官方仍在用 io.Reader/io.Writer 组合，但新增了 io.ToReader 和 io.Seq 辅助构造流式行为 —— 不解决根本问题，只是语法糖。
立即学习“go语言免费学习笔记（深入）”；
- 别指望语言原生支持“声明式滤镜链”，还是得手动串
io.Pipe+ goroutine - 真要简化，推荐封装一个
FilterChain类型，内部管理 pipe 生命周期和错误传播 - 最容易被忽略的是 error 跨 goroutine 传递：写端 panic 了，读端不会自动知道，得靠额外 channel 通知
