io.CopyBuffer 本身不限流，限速必须在 Reader 端（如包装 http.Response.Body）插入 rate.Limiter，缓冲区大小仅影响系统调用效率而非速率上限，多 goroutine 需独占 limiter 实例。
io.CopyBuffer 本身不提供限流能力，别把它和 rate.Limiter 混用
直接调用 io.CopyBuffer 不会限制网络吞吐量——它只是把缓冲区控制权交给你，读写节奏仍由底层 Reader 和 Writer 的阻塞行为决定。限速必须在数据流路径中插入显式节流逻辑，比如包装 http.Response.Body 或自定义 io.Reader，而不是靠改缓冲区大小“碰运气”。
常见误解是：把缓冲区设小（比如 make([]byte, 4096)）就能压低带宽。实际效果相反：小缓冲导致更多系统调用、更高 CPU 开销，但平均速率未必下降，突发流量反而更明显。
- 限速的正确位置是
Reader端（如响应体），不是Copy调用本身 -
io.CopyBuffer的缓冲区只影响单次Read/Write的 chunk 大小，不干预时间维度上的发放节奏 - 若目标是 HTTP 下载限速，必须用
rate.Limiter包装Response.Body，再传给io.Copy或io.CopyBuffer
限速 Reader 必须介入在 http.Response.Body 和 io.Copy 之间
限速生效的前提，是让每次 Read 都受令牌桶约束。如果直接把原始 Response.Body 交给 io.Copy，限速器根本没机会拦截字节流。
正确链路是：http.Get() → resp.Body → limitedReader → io.Copy(dst, limitedReader)。其中 limitedReader 的 Read 方法里调用 limiter.ReserveN(time.Now(), n)，并按 res.Delay() 睡眠。
立即学习“go语言免费学习笔记（深入）”；
- 不要对
limitedReader再套bufio.NewReader——多一层缓冲会破坏限速精度，因为bufio可能一次预读多于你申请的字节数 - 如果下游
Writer很慢（如写机械硬盘），限速器仍按读取节奏放行，实际速率由写入瓶颈决定，这不是 bug，是设计使然 -
ReserveN可能返回!res.OK()（例如上下文取消），此时必须透传错误，不能忽略
缓冲区大小对限速场景的实际影响很有限
在已加限速的前提下，io.CopyBuffer 的缓冲区大小主要影响单次系统调用的数据量，而非整体速率上限。只要限速器的令牌发放节奏稳定，无论用 8KB 还是 128KB 缓冲，最终吞吐都会收敛到设定值附近。
- 过小（Read 调用频次，放大
limiter.ReserveN的开销，可能引入额外延迟抖动 - 过大（>256KB）：单次申请大量令牌，容易触发
ReserveN返回非零Delay，导致批量阻塞，不如小块匀速更平滑 - 推荐值：32KB–64KB（
make([]byte, 32*1024)），兼顾系统调用效率与限速响应性
并发复制时，每个 goroutine 必须独占 limiter 实例
多个 io.Copy 流程共享同一个 rate.Limiter 实例，会导致令牌被争抢，各流速率不稳定。例如两个下载协程共用一个 512KB/s 的限速器，可能一个占满、另一个饿死。
正确做法是为每个独立数据流创建专属限速器，或用 rate.NewLimiter(rate.Every(...), burst) 的 burst 参数留出合理瞬时余量（如设为 2×平均速率），避免因调度延迟导致卡顿。
- 不要复用
limiter实例跨 goroutine，即使加锁也解决不了令牌分配语义冲突 - 若需全局带宽控制（如整个进程不超过 2MB/s），应在入口处统一限速（如 HTTP client middleware），而非分散到每个 copy
- 注意
rate.Every的单位是时间间隔，不是速率值；rate.Every(time.Second/512000)表示每秒发放 512000 个令牌，对应 512KB/s
