正确做法是用golang.org/x/time/rate.limiter配合自定义io.reader实现限速，每次read前调reserven并按delay休眠，确保平滑控制字节/秒速率；必须包装为io.readcloser，透传multipart boundary，且close()需调用底层body.close()。
限速中间件该用哪个 HTTP handler 包装逻辑
Go 标准库 http.Handler 是唯一正解，别试图在 http.HandlerFunc 里直接读 Request.Body——它会被后续 handler 二次读取导致空 body。必须用 io.LimitReader 包裹原始 req.Body，再替换为新 reader。
常见错误是：在中间件里调用 req.ParseMultipartForm 或 req.FormFile，这会提前消费 body，下游 handler 拿不到文件流。限速必须发生在 body 被解析前。
- 中间件接收原始
*http.Request，只替换req.Body - 限速逻辑不关心请求路径、方法、表单字段，只约束字节流速率
- 替换后的
req.Body必须实现io.ReadCloser接口（io.LimitReader不带Close()，需包装）
如何用 io.LimitReader 实现稳定限速
io.LimitReader 只限制总字节数，不能限速。真正要用的是 golang.org/x/time/rate 的 rate.Limiter 配合自定义 io.Reader。
核心思路：每次 Read(p []byte) 时，先向 limiter 请求 len(p) 令牌，阻塞直到获得许可，再调用底层 reader 的 Read。这样能平滑控制每秒字节数。
- 初始化 limiter：用
rate.NewLimiter(rate.Limit(1024*1024), 1024*1024)表示 1MB/s，burst = 1MB - burst 值太小会导致大文件上传卡顿；太大则瞬时流量可能冲高，建议设为单次
Read最大预期值（如 64KB） - 不要在每次
Read前调用WaitN——它会 panic 当 n > burst；改用ReserveN+Delay判断是否需 sleep
中间件里怎么处理 multipart/form-data 的边界问题
限速器不能破坏 multipart boundary。HTTP body 是二进制流，boundary 是其中一部分字节，限速器必须原样透传，不能截断或修改任何字节。
常见坑：用 bufio.NewReader 包装限速 reader 后调用 ReadString('\n') 解析 header——这会提前读走 boundary 后的换行，导致后续 ParseMultipartForm 找不到 boundary。
- 限速 reader 必须是透明 wrapper，不做任何缓冲或预读
- 如果下游 handler 用
req.MultipartReader()，它内部会自己处理 boundary，限速器无需干预 - 测试时用
curl -F "file=@test.zip" http://localhost:8080/upload，观察服务端Content-Length和实际接收字节数是否匹配
为什么上传完成但文件损坏？检查 Close() 和 error 处理
限速 reader 的 Close() 必须调用底层 req.Body.Close()，否则连接不释放，客户端超时重试，服务端堆积 goroutine。
更隐蔽的问题：限速 reader 的 Read 返回 0, nil 时，不代表结束——可能是 limiter 暂未放行，但底层 reader 已 EOF。必须区分真实 EOF 和限速延迟。
- 每次
Read后检查底层 reader 是否返回io.EOF，如果是，立即返回0, io.EOF - 不要忽略
limiter.ReserveN返回的time.Duration，if delay > 0 { time.Sleep(delay) }必须执行 - 客户端断连时，
Read可能返回0, net.ErrClosed，此时应立刻关闭并返回 error，避免死锁
限速逻辑本身不复杂，但和 multipart、EOF、连接生命周期耦合紧密，漏掉任意一个 Close 或 error 分支，上传就不可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
