io.teereader本质是读取时复制流，不计算哈希；真正计算哈希的是传入的hash.hash实例，需完整读取源流后调用hash.sum(nil)获取结果。
io.TeeReader 本质是“读取时复制流”，不是哈希计算工具
io.TeeReader 本身不计算哈希，它只把从源 io.Reader 读出的每个字节，**原样写入**你指定的 io.Writer（比如 hash.Hash），同时返回给上层读取逻辑。真正做哈希的是你传进去的 hash.Hash 实例——io.TeeReader 只负责“抄送”数据流。
常见误解是以为调用完 io.TeeReader.Read() 就能直接拿到哈希值，其实必须等整个流读完，再调用 hash.Sum(nil) 或 hash.Sum64() 才能得到结果。
- 必须确保所有数据都被
io.TeeReader读过（比如用io.Copy(ioutil.Discard, teeReader)或完整遍历），否则哈希不完整 -
hash.Hash实现（如sha256.New()）本身实现了io.Writer接口，可直接传入，无需包装 - 不能把同一个
hash.Hash实例重复用于多个io.TeeReader，状态会混乱
正确构造 TeeReader + Hash 的典型流程
核心三步：创建哈希实例 → 构造 io.TeeReader → 完整读取源流（触发哈希更新）→ 提取结果。
示例片段（读文件并计算 SHA256）：
file, _ := os.Open("data.bin")
defer file.Close()
hash := sha256.New()
tee := io.TeeReader(file, hash) // 注意：hash 是 io.Writer
// 必须读完全部数据，hash 才会累积完整
if _, err := io.Copy(io.Discard, tee); err != nil {
panic(err)
}
fmt.Printf("%x\n", hash.Sum(nil)) // 输出最终哈希值
-
io.Copy(io.Discard, tee)是最简、最安全的“读完即止”方式；用ReadAll也行，但会把全部内容加载进内存 - 如果后续还要用原始数据（比如解析 JSON），可以把
tee直接传给json.NewDecoder()，它内部会调用Read，自动触发哈希写入 - 不要在
tee读取中途调用hash.Sum()，结果只是当前已读部分的哈希
容易被忽略的性能与边界问题
io.TeeReader.Read() 是同步阻塞的：每次读，它先从源读，再写入 hash，最后返回。这意味着哈希计算和 I/O 是串行的，无法隐藏延迟。
- 对小文件或内存 buffer 影响不大；但对大文件或慢存储（如网络磁盘），哈希成为瓶颈，此时应考虑并发分块哈希（
io.MultiReader+ 分段hash.Hash） -
hash.Write()在底层可能涉及内存分配（如sha256内部缓冲区），高频小读（如每次只读 1 字节）会显著拖慢整体速度——确保上游按合理 buffer size（如 4KB–64KB）读取 - 如果源
Reader支持Seek()，io.TeeReader不继承该能力；想重读必须重建tee和hash
替代方案：什么时候不该用 TeeReader？
当哈希只是副产物，且你 already 在用 bufio.Reader 或自定义解析逻辑时，硬套 io.TeeReader 反而增加复杂度。
- 若需校验读取过程中的中间状态（如每 1MB 输出一次进度哈希），直接在你的
Read循环里调用hash.Write(p)更可控 - 若源是
*bytes.Buffer或[]byte，直接hash.Write(data)比套一层TeeReader更快更直白 - 需要同时计算多个哈希（SHA256 + MD5）？
io.MultiWriter配合多个hash.Hash比嵌套多个TeeReader更简洁
哈希计算本身无副作用，但 io.TeeReader 的“透明转发”特性只有在你确实想复用现有读取逻辑（比如已有基于 io.Reader 的解包函数）时才真正省事。否则，手动 Write 更灵活。
