io.teereader是最轻量的流量镜像方式，它在每次read时将数据同时返回调用方并写入指定writer，不缓冲、不重试、不修改数据，适用于日志、调试等低侵入场景。
用 io.TeeReader 边读边复制到 io.Writer 是最轻量的流量镜像方式
io.TeeReader 本质是把一次读操作“分发”成两份：一份原样返回给调用方，另一份悄悄写进你指定的 io.Writer。它不缓冲、不重试、不修改原始数据流，只做透明转发——所以适合日志记录、调试抓包、简单审计这类低侵入场景。
常见错误是误以为它能“复制整个流供多次读取”，其实它只在每次 Read 时触发一次写入；也不支持 Seek 或 Close 代理，下游 Writer 的错误会直接暴露在 Read 调用中。
- 必须确保传入的
io.Writer是线程安全的（比如bytes.Buffer没问题，但未加锁的os.File在并发Read下可能出错） - 如果目标
Writer写入慢或阻塞，Read也会同步卡住——别把它用在实时性敏感的链路里 - 它不处理 EOF 后的重复读，这点和原始
Reader行为一致，不会多出空数据
复制 HTTP 请求体时，http.Request.Body 需先用 io.NopCloser 包一层再 tee
HTTP 请求体是单次读取的 io.ReadCloser，直接套 io.TeeReader 后，原始 Body 就被“消耗”了，后续框架解析（如 ParseForm）会失败。正确做法是先读完并缓存，再重建一个可重复读的 Body。
但如果你只是想“旁路记录”，又不想全量内存缓存，可以这样折中：
立即学习“go语言免费学习笔记（深入）”；
- 用
bytes.NewBuffer接收TeeReader的副本写入 - 把原始
req.Body替换为io.NopCloser(bytes.NewReader(buf.Bytes())) - 注意：这仍会把全部请求体加载进内存，大文件上传场景慎用
示例关键片段：
buf := &bytes.Buffer{}<br>tee := io.TeeReader(req.Body, buf)<br>// 此时 tee 可用于后续 io.Copy 或 json.Decoder<br>req.Body = io.NopCloser(bytes.NewReader(buf.Bytes()))
TeeReader 和 MultiWriter 组合无法实现“一读多写”，得用 io.MultiReader + 多个 TeeReader
有人想用 io.MultiWriter 把多个日志目标塞进一个 Writer，再丢给 TeeReader——这不行。MultiWriter 是写入时分发，而 TeeReader 的写入目标只能是一个 Writer。真要写多处，必须每个目标配一个 TeeReader，再用 io.MultiReader 合并读取路径。
更现实的做法是：用一个 TeeReader 写入中间缓冲（如 bytes.Buffer），再从该缓冲派生多个读取源。否则并发写不同目标时，各 TeeReader 的读序无法保证一致。
- 不要试图用
os.Pipe模拟多路输出——管道有缓冲限制，容易死锁 -
TeeReader不处理写入失败的回滚，任一Writer返回 error，整个Read就失败 - 若需容错（比如一个日志目标挂了不影响主流程），必须在外层捕获
Write错误并忽略，但标准TeeReader不提供这个钩子
替代方案：需要真正复制/重放能力时，io.TeeReader 就不够用了
当你要做流量回放、AB 测试分流、或协议解析后修改再转发，TeeReader 的单向只读特性就成了硬伤。它不保存数据，也不允许你中途干预字节流。
这时候该考虑：
- 用
io.Copy+bytes.Buffer全量缓存，再用bytes.NewReader创建多个独立读取器 - 对高吞吐场景，改用
io.Pipe构建带缓冲的双向通道，手动控制读写节奏 - 第三方库如
golang.org/x/net/http2/h2c或github.com/gorilla/mux的中间件机制更适合结构化流量处理
最常被忽略的一点：无论用哪种方式，HTTP Header 中的 Content-Length 和 Transfer-Encoding 都不会自动更新——如果复制后修改了 body，必须手动修正 header，否则下游服务可能解析失败。
