Go io.Copy接入限速Reader实现文件传输节流

文件传输不一定要改写 io.Copy。更稳妥的做法是把限速放在读取侧：给源 Reader 包一层带节流逻辑的 Read，再把这个 Reader 交给 io.Copy。这样复制循环、Writer 错误和 EOF 处理仍由标准库完成，限速器只负责控制每次从源端取多少数据、何时取下一块。

把限速放在 Reader，io.Copy 只做数据搬运

如果在复制循环外手写计时，很容易把“读数据、处理错误、写数据、计算等待”揉成一段难以复用的代码。Reader 包装器的接口边界更清晰：源文件、网络响应或压缩流都可以先变成一个限速 Reader，目标端仍然是普通的 io.Writer。

这里的速率指读取侧的近似字节速率，并不是磁盘真实写入速度，也不等价于网络链路的严格整形。io.Copy 可能因为 Writer 较慢自然降速，限速层只在源端读取过快时增加等待。

用固定读取窗口实现一个可复用的限速 Reader

下面的实现把每秒目标字节数换算成单块读取后的等待时间。它保留底层 Reader 返回的 n 和 err，所以当一次读取同时拿到最后一段数据和 io.EOF 时，调用方仍能按标准 Reader 语义处理。

package main

import (
    "io"
    "time"
)

// pacedReader 在读取侧控制节奏，src 的错误不在这里改写。
type pacedReader struct {
    src         io.Reader
    bytesPerSec int64
    chunk       int
    next        time.Time
}

func (p *pacedReader) Read(buf []byte) (int, error) {
    if p.bytesPerSec  0 {
            time.Sleep(delay)
        }
    }
    if len(buf) > p.chunk {
        buf = buf[:p.chunk]
    }
    n, err := p.src.Read(buf)
    if n > 0 {
        // 下一次读取的时间点按实际字节数计算，尾块不会被补成整块。
        wait := time.Duration(float64(n) / float64(p.bytesPerSec) * float64(time.Second))
        p.next = time.Now().Add(wait)
    }
    // n 和 err 必须原样返回，不能吞掉数据后再自行制造 EOF。
    return n, err
}

chunk 决定节流粒度，例如 32 KiB；它越小，速率曲线越平滑，但 Read 调用次数会增加。若源 Reader 直接返回错误，包装器只负责返回，不在这里重试，否则上层无法区分源端失败和限速等待。

接入 io.Copy 时保留复制和关闭责任

使用时只需要把原始 Reader 换成包装器。文件关闭仍由打开它的代码负责，io.Copy 不会替你关闭输入或输出文件；传输失败也要保留返回的错误。

src, err := os.Open("input.bin")
if err != nil {
    return err // 中文说明：打开失败时不创建复制任务。
}
defer src.Close() // 中文说明：函数结束时释放输入文件描述符。

dst, err := os.Create("output.bin")
if err != nil {
    return err // 中文说明：目标文件失败时及时结束，避免继续读取源文件。
}
defer dst.Close() // 中文说明：复制结束后关闭输出文件。

limited := &pacedReader{
    src:         src,
    bytesPerSec: 2 * 1024 * 1024, // 中文说明：这里按约 2 MiB/s 控制读取侧速率。
    chunk:       32 * 1024,        // 中文说明：32 KiB 是本例的节流窗口。
}
_, err = io.Copy(dst, limited) // 中文说明：复制循环仍交给标准库处理。
return err

示例里的速率是配置示意，实际项目应把它作为业务参数，并记录单位是十进制 MB/s 还是二进制 MiB/s。不要把“限速 Reader 返回 nil 错误”当成成功证据，最终结果仍以 io.Copy 的错误为准。

EOF、取消等待和并发共享是三个边界

第一，Reader 允许一次返回 n > 0 与非 nil 错误，因此调用方必须先消费这 n 个字节；限速器不能为了统一格式把它改成 0, io.EOF。第二，time.Sleep 不能响应取消。如果任务需要快速停止，应把等待改为可被 context.Context 唤醒的计时器，并在源 Reader 本身也支持取消时一起传递 context。

第三，当前结构体持有 next 这样的状态，不应被多个并发复制任务共享。要限制整个租户或进程的总带宽，应把令牌桶或时间预算抽成带锁、可取消的独立限速器，再由多个 Reader 共同引用；不要简单地把一个 pacedReader 指针塞进多个 goroutine。

常见问题

为什么不直接在 Writer 侧限速？

Writer 侧也能做节流，但它更容易把“写入变慢”和“读取预算”混在一起。把策略放在 Reader 侧可以复用同一套 io.Copy 逻辑；如果业务关心的是出口带宽，则应根据链路位置选择 Writer 或共享令牌器。

chunk 应该设置多大？

可以从 16 KiB 或 32 KiB 起步，再结合目标速率和调用开销调整。块越大，单次突发越明显；块越小，计时与系统调用成本越高。

限速后还需要测量吗？

需要。应分别记录读取字节数、复制错误、取消耗时和实际传输时长。这个 Reader 提供的是读取侧节奏控制，不保证在慢磁盘、慢网络或共享带宽场景下得到同样的端到端速率。