io.Copy 组合限速读取器控制上传带宽

上传文件时，io.Copy 很适合把一个 io.Reader 连到 io.Writer，但它只负责把数据尽快复制完，并不会自动限制带宽。要控制发送速度，可以把限速逻辑放进一个只实现 Read 的包装器，再把这个包装器交给 io.Copy。这样上传主流程仍然清楚，文件、请求体和内存流也能复用同一套接口。

为什么 io.Copy 本身不会替你限速

io.Copy(dst, src) 会从 src 读到 EOF 或错误，再写入 dst，返回已经复制的字节数和首个错误。它的目标是减少样板 I/O 代码，而不是决定网络发送策略。把限速写在调用方的循环里，往往会把读取、写入、错误和重试揉在一起；放在 Reader 边界更容易复用。

包装器只暴露 Read，因此复制代码不需要知道底层是文件、HTTP 请求体还是内存流。需要注意的是，限速器控制的是读取节奏；目标 Writer 自身的缓冲、协议窗口和网络拥塞仍可能让瞬时表现与平均速率不同。

实现一个按字节计时的限速读取器

下面的实现用“下一次允许完成读取的时间点”累计等待量。每次底层读取得到 n 个字节，就按 n / bytesPerSecond 推进时间点。它不会丢弃已经读出的字节，也不会把 io.EOF 当成失败。

package main

import (
    "errors"
    "io"
    "time"
)

// RateLimitedReader 在 Read 边界按字节速率安排等待。
type RateLimitedReader struct {
    r              io.Reader
    bytesPerSecond int64
    next           time.Time
}

// NewRateLimitedReader 创建一个串行使用的限速读取器。
func NewRateLimitedReader(r io.Reader, bytesPerSecond int64) (*RateLimitedReader, error) {
    // 速率为零或负数时无法定义等待时间，直接返回配置错误。
    if r == nil || bytesPerSecond  0 {
        time.Sleep(wait)
    }
    // n 可能大于 0 且 err 为 io.EOF，已读数据必须先交给调用方。
    return n, err
}

这个版本适合一个复制循环独占一个读取器。它的速率是平均意义上的上限，读取缓冲区越大，单次读取形成的突发就越明显；想让网络曲线更平滑，可以降低复制缓冲区大小，但代价是系统调用次数增加。

把包装器接到上传复制链路

创建好读取器后，上传逻辑仍然只需要一次 io.Copy。下面示例用文件作为源、用一个目标 Writer 表示上传连接；真实项目中目标可以是 HTTP 请求体、对象存储 SDK 的 Writer 或其他实现。

func copyUpload(dst io.Writer, src io.Reader, rate int64) (int64, error) {
    // 包装源 Reader，让 io.Copy 的每次读取都经过限速边界。
    limited, err := NewRateLimitedReader(src, rate)
    if err != nil {
        return 0, err
    }

    // io.Copy 返回已写字节数；错误交给上层决定重试或清理临时对象。
    written, err := io.Copy(dst, limited)
    if err != nil {
        return written, err
    }
    return written, nil
}

错误处理不要只检查 io.Copy 的返回值是否为零：网络断开时可能已经写入一部分数据，written 可用于记录进度、判断临时对象是否需要删除。若上层支持取消，应让目标 Writer 或源 Reader 自己响应上下文；这个包装器只负责等待，不会凭空中断底层 I/O。

检查速率、突发与并发边界

还要留意 io.Copy 对 WriterTo 和 ReaderFrom 的优化路径。包装器本身只提供 Read，能把控制点固定在读取接口；但如果项目使用了自定义 Writer，仍应确认它不会绕过源 Reader 的读取语义。限速不是并发控制，也不是断点续传协议，三者应分别设计。

相关问题

限速应该放在 Writer 还是 Reader？

上传方向通常放在源 Reader 更直观，因为复制链路每次取数据前后都经过包装器；若多个来源共享一个出口，应该在更靠近共享出口的位置使用统一限速器。

为什么设置了速率仍会出现短暂突发？

读取缓冲区和底层协议都会形成批量写入。文章示例限制的是平均字节速率，不承诺每个瞬间都严格相同；需要硬突发上限时要再增加令牌桶的 burst 约束。

能否直接在循环里 time.Sleep？

可以做最小实验，但容易漏掉短读、错误返回和多任务共享配额。把等待逻辑封装成 Reader 后，复制、统计和资源清理更容易分别测试。