关键在于用 rate.limiter 包装读取路径并每次 read 前调 reserven+wait 申请对应字节数令牌；io.limitreader 无法实现每秒限速因其无时间维度、不支持动态调整且易被 http 预读耗尽限额。
直接控制文件读取速度，关键不是改 os.File，而是用 rate.Limiter 包装读取路径，并确保每次 Read() 前精确申请对应字节数的令牌——否则速率会漂移、卡顿或翻倍。
为什么 io.LimitReader 不能实现“每秒 N 字节”
io.LimitReader 只限制总字节数，不带时间维度，完全无法控制速率。它常被误用于限速场景，结果是：文件读完才停止，中间毫无节奏感，和“限速”目标背道而驰。
- 它不感知时间，无法按秒配额
- 无法重置或动态调整，一旦初始化就固定上限
- 与
http.Client或multipart.Writer配合时，因多次调用Read()导致提前耗尽限额，上传中断在 99%
正确封装 rate.Limiter 实现字节级限速 Reader
核心是把 rate.Limit 单位设为 bytes/sec（不是 events/sec），并用 ReserveN + Wait 主动控制节奏，而非依赖 AllowN 这种非阻塞判断。
- 初始化时用
rate.Limit(1024 * 1024)表示 1MB/s，避免rate.Every(time.Second / bps)被编译器优化掉除法 -
burst至少设为等于 limit（如 1MB/s → burst = 1024 * 1024），否则重试或预读可能直接被拒 - 每次
Read(p []byte)前必须调limiter.ReserveN(ctx, len(p))，再立刻res.Wait(ctx)；漏掉Wait就等于没限速 - 不要复用同一个
limiter实例给多个 goroutine，否则速率分配不均；每个读流应独占一个 limiter
上传场景必须加 io.Pipe + goroutine 隔离状态
HTTP 客户端（包括 net/http 和 multipart）会预读、缓冲、重试，反复调用同一个 io.Reader.Read()。若限速逻辑无状态隔离，一次读触发多次令牌扣除，速率失控、连接卡死。
- 正确做法：起一个 goroutine，从限速
io.Reader读，往io.PipeWriter写；http.Request.Body或part.Write()用io.PipeReader -
io.PipeWriter.Close()必须由写端显式调用，否则读端永久阻塞 - goroutine 中需
defer func() { recover(); writer.Close() }()，防止 panic 导致连接泄漏 - 大文件（>100MB）慎用管道，
multipart内部 buffer 可能吃光内存；此时应改用分块 + 显式part.Write()+ 每次写前限速
下载时别在 http.Response.Body 上 sleep
对原始 Response.Body 加 time.Sleep 会阻塞底层 TCP 连接，影响连接复用，还可能触发服务端超时断连。限速点必须落在数据消费侧，即 io.Copy 的 dst 或中间 reader。
- 推荐链路：
http.Response.Body→ 限速io.Reader→io.Copy(dst, limitedReader) - 不要用
ReadFull，它要求填满缓冲区，小块读时易返回io.ErrUnexpectedEOF；改用io.ReadAtLeast或手动处理 partial read - 限速单位统一用
bytes/sec，避免 KB/s 级整数除法丢失精度（比如 1023999 bytes/sec 比 1024 KB/s 更准）
真正难的不是写限速逻辑，而是识别哪一层读取行为会被 HTTP 栈多次触发——这决定了你是否必须引入 io.Pipe。多数人栽在“以为 Read 只调一次”，结果上传卡在 99% 还查不出原因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
