Go io.SectionReader 在重试下载中复用读取边界

Go io.SectionReader 适合保存“从底层 ReaderAt 的哪个偏移读取多少字节”这一边界。重试时应复用源对象、起点和长度，并为每次尝试创建新的 SectionReader；直接复用已经读到末尾的实例，下一次顺序读取会继续沿用旧游标。

它解决的是有界读取，不会自动重试网络请求、撤销目标已写出的内容或固定源文件版本。这里给出一个最小读取配方，再说明怎样接入下载任务；不把示例包装成完整 HTTP 断点续传系统。

官方文档：https://pkg.go.dev/io#SectionReader。

先把可复用的区间参数保留下来

假设下载服务要从一个本地资源中发送指定片段。第一次复制失败后，如果仍把同一个 reader 交给下一次复制，它可能从中途继续，也可能立即遇到 EOF。要复用的应该是区间描述，而不是已经消耗过的顺序读取状态。

区间由底层源、起始偏移 off 和字节数 n 组成。它对应从 off 开始的 n 个字节，不是“off 到 n”的两个端点。若起点为7、长度为7，描述的就是从底层偏移7开始的7个字节。

最小写法：每次尝试创建新的SectionReader

下面用一个小型不可变内存源演示两次独立尝试。每次创建新的读取器和空目标；第二次调用只演示重复读取同一区间，不是在虚构第一次网络失败。

package main

import (
    "bytes"
    "fmt"
    "io"
)

type Window struct {
    Source io.ReaderAt
    Offset int64
    Length int64
}

func (w Window) CopyAttempt(dst io.Writer) (int64, error) {
    // 参数由调用方保存；拒绝负值及偏移加长度溢出。
    const maxInt64 = int64(1 maxInt64-w.Length {
        return 0, fmt.Errorf("无效读取区间")
    }
    // 每次调用都有新游标，绝不沿用上一次已消耗的Read位置。
    reader := io.NewSectionReader(w.Source, w.Offset, w.Length)
    copied, err := io.Copy(dst, reader)
    if err != nil {
        return copied, fmt.Errorf("复制区间: %w", err)
    }
    if copied != w.Length {
        // 源数据提前结束时，io.Copy可能以nil错误结束，需另看长度。
        return copied, io.ErrUnexpectedEOF
    }
    return copied, nil
}

func main() {
    // 小型不可变内存源仅用于解释读取区间，不是网络下载实现。
    source := bytes.NewReader([]byte("header|payload|tail"))
    window := Window{Source: source, Offset: 7, Length: 7}
    for attempt := 0; attempt 

示例按字符串位置推演，两次都应得到 payload 这7个字节。这里未执行代码，不提供运行记录。把内存源换成文件时，要让文件在所有尝试期间保持打开，并由持有者统一关闭。

函数检查非负区间并避免偏移相加溢出。实际服务还应根据已知资源长度判断请求是否超出范围、限制资源消耗，并定义零长度区间的业务含义。

读取不足与目标端重试应分别处理

SectionReader 限制最多读取区间内的内容，但不保证底层一定存在这么多字节。源提前结束时，io.Copy 可以返回已复制数量和 nil，因为遇到 EOF 不一定被它当作复制失败。因此，业务要求恰好传完 n 字节时，还应比较返回数量。

读端复位也不等于目标复位。如果第一轮已经把前半段写入文件或远端，第二轮从头重发可能造成重复内容。可以为独立尝试准备新临时目标，或让目标协议具备明确的偏移、覆盖及确认规则；不能只在读取器外面套一个循环。

还要判断错误是否适合重试。参数无效或源长度不足，并不会因为再次创建读取器就自动恢复。真实重试策略需要次数限制、取消信号和源版本约束，这些职责不属于 SectionReader。

游标复位、并发读取和资源归属

串行使用同一个实例时，也可以通过 Seek(0, io.SeekStart) 返回区间开头。这里的0相对于区间，不是底层资源的绝对偏移0。每次新建实例更容易隔离尝试状态，但两种写法都不能改变底层数据。

Go 1.22 起的 Outer() 可以取回创建时的底层 ReaderAt、off 和 n。它返回原区间参数，不是剩余未读区间；为了兼容不使用该方法的代码，也可以像示例一样显式保存 Window。

不要让多个 goroutine 同时对同一个实例执行 Read 和 Seek，共享游标会让读取位置难以控制。并行尝试应分别持有 SectionReader，并确保底层 ReaderAt 的实现及源生命周期满足并发访问要求。

SectionReader 本身没有 Close 方法，它不接管底层文件的关闭。外层对象只保存了读取边界，也不是文件内容快照；同一文件在两次尝试之间被修改，可能导致相同区间返回不同数据。

接入HTTP下载时的边界与常见问题

若作为下载服务的发送端，将数据写入 ResponseWriter 后，响应头和正文可能已经提交。此时不能再把同一响应当作空白目标，从区间开头重新写一遍；重建 reader 不会让客户端忘掉已经收到的字节。

浏览器重新请求、客户端断点续传与服务端内部重读是不同层面的动作。需要 HTTP Range 时，还要另行处理区间请求、响应状态、长度和资源版本。本文配方只承担从已支持 ReaderAt 的源重复读取同一边界。

能直接套在http.Response.Body上吗？ 不能默认这样做。构造函数需要 ReaderAt，普通响应正文是顺序读取接口，不自动具备按偏移读取能力。可先缓存为受控文件，或使用明确支持随机读取的源。

把Size当作本次剩余量可以吗？ 不可以。它表示区间大小，不随顺序读取游标递减。要记录本次已传多少，应使用复制返回的字节数或独立进度记录。

为什么重新构造后仍读到不同内容？ 先确认源是否变化、ReaderAt实现是否稳定，以及调用方保存的起点和长度是否一致。读取边界相同并不证明底层字节版本相同。

参考：io.SectionReader 文档；Go io 实现；HTTP ResponseWriter 文档。