Go bytes.Reader 读取后如何复位：Seek、Reset 与并发复用边界

把同一段请求体交给两个解析步骤时，很多人会发现第二次读取直接得到空结果。问题通常不在数据消失，而在 bytes.Reader 的读取位置已经到了末尾。复位时，Seek、重新调用 NewReader 和给别的类型调用 Reset 解决的不是同一件事。

bytes.Reader 只保存读取游标和原始字节切片；读完后优先用 Seek(0, io.SeekStart) 回到开头，想换数据就重新创建 Reader。不要把 bytes.Buffer.Reset 的习惯套到 bytes.Reader 上，也不要让多个 goroutine 直接共享一个 Reader。

第二次读取为什么从空字节开始

bytes.NewReader 返回的 Reader 从位置 0 开始。每次成功读取都会推进内部偏移，直到偏移等于数据长度。下面的程序故意连续读取两次，第二次拿到的是 io.EOF，并不是底层 []byte 被清空。

package main
import ("bytes"; "fmt"; "io")
func main() {
    reader := bytes.NewReader([]byte("go-reader"))
    first, firstErr := io.ReadAll(reader)
    second, secondErr := io.ReadAll(reader)
    fmt.Printf("first=%q err=%v\n", first, firstErr)
    fmt.Printf("second=%q err=%v\n", second, secondErr)
}

第一次 io.ReadAll 把位置推进到末尾，第二次调用仍然面对同一个位置，所以返回空切片和 io.EOF。变化的是 Reader 的游标。

只想重新读一遍时用 Seek

复用同一份字节数据、只把阅读位置退回去，应该调用 Seek(0, io.SeekStart)。它返回新的绝对偏移；如果返回错误，要把错误当成复位失败处理。

reader := bytes.NewReader([]byte("go-reader"))
_, _ = io.ReadAll(reader)
position, err := reader.Seek(0, io.SeekStart)
if err != nil { panic(err) }
again, err := io.ReadAll(reader)
fmt.Printf("position=%d value=%q err=%v\n", position, again, err)

对 bytes.Reader 来说，起点是 0，io.SeekStart 让调用意图更清楚。不要用 Seek(-n, io.SeekCurrent) 猜当前位置。

换一份数据时重新创建 Reader

Seek 不会替换 Reader 看到的字节。如果任务要处理另一份内容，直接建立新的 Reader 更容易核对，也不会把旧游标带进新流程。

oldReader := bytes.NewReader([]byte("old"))
_, _ = io.ReadAll(oldReader)
newReader := bytes.NewReader([]byte("new"))
value, err := io.ReadAll(newReader)
fmt.Printf("value=%q err=%v\n", value, err)

这里的 newReader 从 0 开始，且绑定新的字节切片。换数据时同时替换 Reader 字段，通常比修改外围切片更不容易误读。

Reset 不是 bytes.Reader 的复位方法

经常被混淆的是 bytes.Buffer.Reset。Buffer 负责可增长的读写缓冲，Reader 负责围绕一段已有数据提供读取视图；两者 API 名字相似，但复位对象不同。

buffer := bytes.NewBufferString("old")
buffer.Reset()
buffer.WriteString("new")
fmt.Println(buffer.String())
reader := bytes.NewReader([]byte("old"))
// reader.Reset([]byte("new")) // 编译失败：bytes.Reader 没有 Reset
_ = reader

需求是清空可写缓冲，就使用 Buffer 的 Reset；需求是同一段只读数据再读一次，就使用 Reader 的 Seek；需求是切换数据源，就重新调用 bytes.NewReader。

并发复用时先处理游标竞争

bytes.Reader 的读取位置属于对象自身。两个 goroutine 同时调用 Read、Seek 或 ReadAt 时，不能把它当成自动同步的共享资源。最稳妥的做法是每个任务创建自己的 Reader；确实要共享时，至少把会改变游标的操作放在同一把 sync.Mutex 里。

type SharedReader struct {
    mu sync.Mutex
    reader *bytes.Reader
}
func (s *SharedReader) ReadAllFromStart() ([]byte, error) {
    s.mu.Lock(); defer s.mu.Unlock()
    if _, err := s.reader.Seek(0, io.SeekStart); err != nil { return nil, err }
    return io.ReadAll(s.reader)
}

这段保护的是“Seek 到起点再 ReadAll”的整体过程，而不只是单独一行。若只锁住 Seek，另一个 goroutine 仍可能在读取期间推进同一个游标。

用三个检查点判断该选哪种方式

只读同一份内容两次

保留 Reader，完成第一次读取后检查 Seek(0, io.SeekStart) 的错误，再开始第二次读取。

任务之间互不影响

不要共享 Reader；在任务入口用同一份原始字节分别调用 bytes.NewReader。这样每个任务都有独立游标，通常也不需要锁。

对象需要持续写入

检查代码是不是其实需要 bytes.Buffer。只有 Buffer 才适合通过 Reset 清空当前缓冲并继续写入。

相关问题

Seek 回到 0 后会复制底层字节吗？

不会。Seek 只调整 Reader 的位置，不负责复制原始字节。需要独立数据快照时，应在创建 Reader 前明确复制切片。

ReadAt 会不会改变当前游标？

使用 ReadAt 做指定偏移读取时，调用者仍应把它和普通 Read 的游标语义分开验证，不要据此推断整个对象可以安全并发复用。

读完以后重新调用 bytes.NewReader 有什么代价？

它创建一个新的 Reader 状态，通常只带来很小的对象开销；换数据或隔离任务时，这种明确性往往比共享游标更有价值。

记住一个简单判断：位置回到开头用 Seek，数据换了用 NewReader，可写缓冲清空才用 Reset。再把 Reader 的生命周期放到单个任务里，绝大多数“第二次读不到”和并发读乱序问题都能在设计阶段消失。