io.LimitReader 本质是限总字节数而非速率，正确限速需用 rate.Limiter 实现令牌桶，每次 Read 前调用 WaitN 按实际读取字节数扣额，并确保下游写入不成为瓶颈。
用 io.LimitReader 包裹响应体最直接
限速本质是控制单位时间读取的字节数，io.LimitReader 正好做这件事：它在底层 reader 上加一层“带速率桶”的包装，每次 Read 都按配额放行。关键不是“限制下载总大小”，而是“限制每秒读多少字节”——所以得配合时间控制。
- 不要对整个
http.Response.Body直接套io.LimitReader后就丢给io.Copy，那样只会限总字节数（比如限 1MB 就停），不是限速 - 正确做法是写一个自定义
io.Reader，内部用time.Sleep或rate.Limiter做令牌桶，每次Read前等够时间再读指定字节数 - 如果只是简单测试或内部工具，用
rate.Limiter最稳：limiter := rate.NewLimiter(rate.Limit(1024*1024), 1024*1024)表示 1MB/s，burst=1MB
rate.Limiter 比手动 sleep 更准、更抗突发
手动 time.Sleep 容易受系统调度影响，尤其小包频繁读时误差大；rate.Limiter 内部用浮点精度计算允许时间点，支持平滑限速，还能处理突发流量（burst 参数）。
- 初始化时 burst 值至少等于每秒限额，否则第一次读就可能被卡住（
WaitN返回 error） - 必须在每次
Read前调用limiter.WaitN(ctx, n)，其中n是本次想读的字节数，不能固定写死 1024 —— 实际Read可能返回更少，得用真实返回值去扣额度 - 别在 goroutine 里单独跑限速逻辑再 channel 传数据，容易丢字节或阻塞死锁；限速和读取必须耦合在同一调用路径上
写文件时别让 os.File.Write 成为瓶颈
限速逻辑生效的前提是：下游写入不拖慢整体流程。如果磁盘慢或用了小 buffer，Write 变成阻塞点，限速就失效了——你以为卡在限速，其实是卡在磁盘。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
bufio.NewWriterSize(f, 1 开 1MB 缓冲，避免高频小 write - 不要边读边写（
io.Copy默认行为），改用循环 +Read/Write+ 显式限速，才能精确控制节奏 - 如果目标是网络传输（比如代理下载），注意
http.ResponseWriter的 write timeout 可能比限速还早触发，需同步调大WriteTimeout
HTTP 头里要不要发 Content-Length？
要，但不能瞎发。限速本身不影响 header，但如果你用 io.LimitReader 截断响应体，又没改 Content-Length，客户端会收一半就报 “unexpected EOF”。
立即学习“go语言免费学习笔记（深入）”；
- 如果源服务返回了
Content-Length，且你没修改 body 长度，就原样透传 - 如果做了限速+截断（比如只下前 10MB），必须删掉原
Content-Length，改用Transfer-Encoding: chunked，或者干脆不设长度（HTTP/1.1 允许） - 浏览器下载时，缺失
Content-Length会导致进度条消失，但不影响功能；命令行工具如 curl 会显示 “-” 而不是百分比
