限流必须在读写环节介入，不能仅靠time.sleep；应基于io.reader实现令牌桶限速读取器，用golang.org/x/time/rate控制速率，确保数据流各环节统一控速。
限流必须在读写环节介入，不能只靠 sleep
Go 的 io.Copy 默认不感知速率，直接调用会打满带宽。限流必须插在数据流动路径中——要么包装 Reader，要么包装 Writer，或者用带节流的中间层。单纯在循环里 time.Sleep 不可靠：它无法补偿系统调度延迟、GC 暂停或磁盘 I/O 波动，实际速率抖动极大，尤其在高并发或低配机器上容易超限。
推荐做法是基于 io.Reader 实现一个带令牌桶的限速读取器，把限流逻辑和数据流绑定。这样无论下游是网络写入、本地文件写入还是加密处理，都能统一控速。
用 golang.org/x/time/rate 构建可复用的限速 Reader
标准库没有内置限速 Reader，但 golang.org/x/time/rate 提供了稳定的令牌桶实现。关键点在于：每次 Read 前申请对应字节数的令牌，阻塞等待（或非阻塞失败），再执行真实读取。
-
rate.NewLimiter初始化时传入limit（每秒令牌数）和burst（最大突发量），例如rate.NewLimiter(10 表示均值 10MB/s，允许最多 2MB 突发 - 封装的
ThrottledReader需重写Read(p []byte)方法，在调用底层Read前调用limiter.WaitN(ctx, len(p)) - 注意：
WaitN可能返回context.Canceled或context.DeadlineExceeded，需透传错误，不能忽略 - 不要对小 buffer（如 4KB）频繁调用
WaitN，建议用足够大的 buffer（如 64KB–1MB），减少令牌申请次数，避免调度开销放大
大文件传输中 write-side 限流更稳定，但需适配协议
如果传输走 HTTP 或 gRPC，限流放在写端（即服务端响应写入）通常比读端更可控：客户端接收速度不可控，而服务端能精确决定发包节奏。但要注意协议层缓冲的影响：
- HTTP 的
ResponseWriter底层有bufio.Writer，默认 4KB 缓冲，可能导致限流“滞后”——令牌已扣减，但数据还没真正发出 - 解决办法：显式调用
http.Flusher（若支持），或设置小 buffer（如bufio.NewWriterSize(w, 8192)），并定期Flush() - gRPC 流式响应需用
SendMsg而非Send，后者可能批量合并；同时设置grpc.MaxConcurrentStreams和grpc.KeepaliveParams防连接僵死 - 若用
net.Conn直传，务必禁用 Nagle 算法：conn.SetNoDelay(true)，否则小包攒批会破坏限速精度
实测发现 burst 设置不当会导致吞吐骤降或突刺
限速效果高度依赖 burst 参数。设得太小（如等于 rate），会把流量压成“锯齿波”，实际吞吐远低于目标；设得太大（如 >5×rate），则初期全速冲击，可能触发对方 TCP RST 或被防火墙限频。
建议按典型 chunk 大小设置 burst：比如用 128KB buffer 读写，burst 至少设为 128 * 1024 * 2（2 个 buffer），既防抖动又控突刺。线上环境应结合监控调整——观察 rate.Limit() 返回值与实际发送速率偏差，偏差 >15% 就需调参。
真正麻烦的是跨设备场景：同一限流配置在 SSD 和 HDD 上表现差异极大，因为 I/O 延迟不同导致令牌消耗节奏偏移。这种情况下，仅靠 rate.Limiter 不够，得加 I/O 延迟反馈环，但多数业务没必要这么复杂——先用固定 burst + 大 buffer 跑起来，再看是否真需要动态调参。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
