io.teereader不能分流到多个目标，仅支持单writer镜像；需用bytes.buffer中转或multiwriter组合实现伪多写，但后者错误会传播且无法隔离。
io.TeeReader 不能直接“分流读取”到多个目标
它只接受一个 io.Writer，返回一个 io.Reader；调用 Read() 时，数据一边返回给调用方，一边写入那个唯一的 w。想“一份输入、写两处”，不能写两次 io.TeeReader(r, w1) 和 io.TeeReader(r, w2)——第二个会读不到数据，因为 r 已被第一个消耗完。
常见错误现象：io.ReadAll 或 json.NewDecoder 解析失败、req.Body 空、日志文件只写了一半。
- 真正需要“一读多写”，得先中转：用
bytes.Buffer或io.Pipe缓存原始流，再从缓存派生多个读取路径 - 若目标是日志+网络响应（如
http.ResponseWriter），别让写入阻塞主流程——io.TeeReader是同步的，任一Write()卡住，整个Read()就卡住 - 不要对
os.File直接用io.TeeReader+ 小 buffer：频繁 syscall 导致性能骤降；应包一层bufio.NewWriter
用 io.MultiWriter + io.TeeReader 实现“伪多写”要小心错误传播
io.MultiWriter(w1, w2) 返回一个 io.Writer，可以喂给 io.TeeReader，看起来像“同时写两处”。但它的行为是：每次 Write() 都顺序调用所有子 Writer，只要其中任意一个返回非 nil 错误，就立刻返回该错误——你无法单独捕获 w1 成功而 w2 失败的情况。
使用场景：调试时同步输出到 os.Stdout 和临时文件，且能容忍任一目标失败即整体失败。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
io.MultiWriter不做缓冲，也不重试，写入慢的目标会拖慢整个读取节奏 - 如果
w1是net.Conn、w2是磁盘文件，网络抖动会导致Read()延迟，影响 HTTP 响应时间 - 错误信息里不会说明是哪个
w出错，需自行包装每个Writer做日志或状态标记
HTTP Body 复制必须重建可重复读的 Reader
http.Request.Body 是一次性 io.ReadCloser，直接套 io.TeeReader 后，框架后续调用 ParseForm() 或 json.NewDecoder(req.Body).Decode() 会读到 EOF 或空内容。
正确做法不是“绕过”，而是显式接管生命周期：
- 用
bytes.Buffer接收io.TeeReader的副本写入：buf := &bytes.Buffer{}; tee := io.TeeReader(req.Body, buf) - 消费
tee（比如传给io.Copy(ioutil.Discard, tee)或json.NewDecoder(tee).Decode()） - 重建
req.Body = io.NopCloser(bytes.NewReader(buf.Bytes()))，供后续中间件或框架使用 - 注意：这会把全部请求体加载进内存，上传大文件（>100MB）时慎用；真要处理大流，得用
io.Pipe+ goroutine 拆流，并手动处理关闭和错误同步
写入失败会被吞掉，必须手动检查
io.TeeReader 的文档明确说：“写入时遇到的任何错误都会作为读取错误返回”。但实际中，很多用户没意识到——它只在 Read() 调用期间暴露错误，且一旦 Write() 失败，整个 Read() 就返回错误，下游可能直接 panic 或丢弃剩余数据。
容易踩的坑：日志写入磁盘满、网络 Writer 连接中断、权限不足，但程序没报错、日志文件为空，还以为“复制成功了”。
- 别依赖
io.Copy(dst, tee)就万事大吉——它内部循环Read()，错误会终止复制，但你没机会知道是哪次Write()出的问题 - 安全做法：自己封装一层，例如
safeTeeReader(r io.Reader, w io.Writer)，在每次w.Write()后检查err并记录，或提前sync.Once标记写入失败状态 - 如果目标
w是os.File，记得用file.Sync()强制落盘，否则断电可能导致日志丢失
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
