Go服务端限速核心是控制http.ResponseWriter的Write节奏，必须用github.com/juju/ratelimit按字节限速，而非标准rate.Limiter；需先WriteHeader、避免gzip绕过、透传Flush，并处理Content-Length与上下文超时。
Go 服务端限速的核心是控制 http.ResponseWriter 的 Write 调用节奏，不能动连接底层，也不能依赖客户端行为——必须在写响应体时主动节流。
用 ratelimit.Writer 包装 ResponseWriter 最稳
标准库 golang.org/x/time/rate 不适合字节级限速，它只认“次数”，不是“字节数”。真正该用的是 github.com/juju/ratelimit，它专为吞吐设计，单位是字节/秒。
-
ratelimit.NewBucketWithRate(1024*1024, 1024*1024)创建一个 1MB/s 的桶，容量设为等于速率，避免首包被卡住 - 包装前必须先调用
w.WriteHeader(statusCode)，否则Write可能触发 header 自动写入，导致状态码错误 - 不要包装原始
http.ResponseWriter后直接传给 gzip 中间件——gzip 会绕过你的限速；应在压缩之后再限速，即包装gzipResponseWriter或自定义ResponseWriter实现 - 若 handler 里用了
io.Copy，得替换成手动分块Read/Write+ratelimit.Writer，否则io.Copy会一次性读完、不走限速逻辑
rate.Limiter 不能直接用于 response 写入
有人试过 limiter.WaitN(ctx, len(p)) 插在 Write 前，但容易出问题：如果某次写入很小（比如 1 字节），WaitN 等待时间可能远超预期，导致响应延迟抖动剧烈；而且 rate.Limiter 的 Burst 是“次数”，不是字节，设成 1024*1024 并不表示“允许突发 1MB”，而是“允许突发 1024*1024 次调用”——完全错位。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 错误示范：
limiter := rate.NewLimiter(rate.Every(time.Second/1000000), 1024*1024)→ 这是在限“每秒一百万次写操作”，不是“每秒一百万字节” - 正确做法：用
juju/ratelimit，它的NewBucketWithRate第一个参数就是 fillRate（字节/秒），语义清晰、无歧义 - 别自己手写 ticker + sleep 控制写节奏——难以应对小块写入、网络缓冲、client 接收慢等现实因素，
ratelimit.Writer内部已做平滑处理
大文件下载场景下必须处理 Content-Length 和超时
限速后单次 Write 耗时变长，若没配好超时，HTTP client 可能因等待响应而断连，服务端却还在写，造成 goroutine 泄漏。
立即学习“go语言免费学习笔记（深入）”；
- 务必显式设置
w.Header().Set("Content-Length", strconv.FormatInt(fileSize, 10))，否则Transfer-Encoding: chunked会让限速效果不可控（chunk 大小不固定） - handler 函数入口加
ctx, cancel := context.WithTimeout(r.Context(), 5*time.Minute)，并在每次Write前检查ctx.Err()，及时退出 - 不要依赖
http.Server.ReadTimeout或WriteTimeout—— 它们已弃用，且无法区分“正常限速等待”和“真卡死” - 如果文件来自磁盘，用
http.ServeFile或http.FileServer时无法插限速逻辑，必须自己实现io.Reader+ratelimit.Reader+io.Copy流式输出
最易忽略的一点：限速 Writer 必须透传 Flush() 调用。如果你包装了 ResponseWriter 却没实现 Flush() 方法，SSE 或流式 JSON 场景下数据会滞留在缓冲区，客户端永远收不到——这和速率无关，但会让限速功能看起来“失效”。
