Go 文件上传限速必须在读取原始文件流时控制，用 ratelimit.Reader 最简捷；手动实现需结合 rate.Limiter 与 io.Pipe 并严格处理 ReserveN 和 Close，否则失效。
Go 文件上传限速不能靠 HTTP 客户端配置或中间件拦截，必须在「读取原始文件流」这一侧插入速率控制逻辑，否则会被 multipart 预读、client 缓冲、重试等行为绕过。
用 ratelimit.Reader 包裹文件流最省事
第三方库 github.com/juju/ratelimit 提供开箱即用的令牌桶封装，比手写 rate.Limiter + io.Pipe 更少出错：
- 直接对
*os.File或multipart.Part做包装，无需额外 goroutine 或管道 - 支持
Range请求（io.LimitReader不支持） - 内部已处理分块等待逻辑，调用方只需把返回的
io.Reader传给part.Write或http.NewRequest.Body - 示例：
limitedReader := ratelimit.Reader(file, ratelimit.NewBucketWithRate(1024*1024, 1024*1024))表示限速 1MB/s，桶容量 1MB
rate.Limiter + io.Pipe 是精确控制的底层方案
当需要与 context 超时强绑定、或需在限速中插入日志/监控/熔断逻辑时，必须手动控制读取节奏：
- 漏掉
res.Wait(ctx)就等于没限速——limiter.ReserveN只是预检，不阻塞 - 每次
Read(p []byte)前都要调limiter.ReserveN(now, len(p))，且now必须实时传入，否则窗口漂移 - 必须配
io.Pipe：HTTP client 可能多次调Read，没有管道会导致重复 Reserve、速率翻倍或死锁 -
io.PipeWriter.Close()必须由写端 goroutine 触发，否则读端永远 hang 在Read
别踩这些坑
常见失效场景和错误写法：
立即学习“go语言免费学习笔记（深入）”；
- 对整个文件用
io.LimitReader(file, totalSize)—— 这只限制总长度，不是速率 - 把限速 Reader 直接传给
http.NewRequest的Body，而不走io.Pipe—— multipart 场景下会卡死或触发多次读取 -
rate.NewLimiter(rate.Every(time.Second/1024*1024), 1024*1024)——rate.Every参数是时间间隔，不是字节数；正确写法是rate.NewLimiter(rate.Limit(1024*1024), 1024*1024) - 用
background.Context()调WaitN—— 上传中途 cancel 无法中断，资源泄漏
真正难的不是选哪个库，而是理解「限速必须发生在数据被消费的那一刻」：上传流的消费者是 multipart 写入器或 HTTP client 的底层 reader，不是你的 handler 函数。所有绕过这个位置的封装，都会在大文件、高并发、网络波动时露出破绽。
