直接用http.ServeFile会压垮服务器，因为默认为每个并发请求分配goroutine和完整缓冲区，导致内存与带宽瞬间打满，触发OOM或连接超时堆积；其不支持限流，且无法处理Range等HTTP协商，必须改用http.ServeContent配合io.LimitReader和rate.Limiter实现字节级限速，并配合MaxConnsPerHost或LimitListener控制并发连接数。
为什么直接用 http.ServeFile 会压垮服务器
不做限流时，一个大文件被并发下载几十次，net/http 默认为每个请求分配 goroutine 和完整文件读取缓冲区，内存和带宽瞬间打满。常见现象是 runtime: out of memory 或连接超时堆积，但错误日志里往往只看到 context deadline exceeded，实际根源在 I/O 层没控速。
- 单个
os.File可被多个 goroutine 并发读，但底层系统调用（如read()）仍争抢内核缓冲区，容易触发 page cache 污染或磁盘 I/O 饱和 -
http.ServeFile不提供读取节流接口，无法控制每秒读多少字节 - 用
time.Sleep在 handler 里硬限流会阻塞 goroutine，导致连接数虚高、超时误判
用 io.LimitReader + http.ServeContent 实现按字节限流
核心思路是：不改写整个响应流程，而是在数据写入前插入限速层。关键点是必须配合 http.ServeContent（而非 http.ServeFile），否则 Range 请求、If-None-Match 等 HTTP 协商逻辑会失效。
- 先用
os.Stat获取文件大小和修改时间，构造http.ServeContent所需的modtime和size - 创建一个包装了原始
io.ReadSeeker的限速 reader：io.LimitReader(file, maxBytes)不行——它只限制总字节数；要用golang.org/x/time/rate.Limiter配合自定义io.Reader - 示例关键片段：
func limitedFileReader(f *os.File, limiter *rate.Limiter) io.ReadSeeker {
return &limitedReader{
f: f,
limiter: limiter,
}
}
func (r *limitedReader) Read(p []byte) (n int, err error) {
n, err = r.f.Read(p)
if n > 0 {
r.limiter.WaitN(context.Background(), n)
}
return
}
注意：这里 WaitN 是阻塞式等待，确保每读 n 字节就耗掉对应令牌，比按固定周期 Sleep 更精准。
为什么不能只限速 reader，还要控制并发连接数
限速 reader 解决带宽问题，但不解决连接数爆炸。比如 100 个客户端同时发起请求，即使每个只跑 10KB/s，也会起 100 个 goroutine 占用栈内存和调度开销。Go 默认 http.Server.MaxConnsPerHost 是 0（无限制），必须显式设防。
- 用
http.Server的MaxConnsPerHost（Go 1.19+）或第三方中间件如golang.org/x/net/http/httpproxy不够直接；更可靠的是用net.Listener包装器 - 简单实现：维护一个计数器 +
sync.Mutex，Accept时检查是否超限，超限则conn.Close()并返回http.ErrServerClosed（客户端收到 connection reset） - 更健壮的做法是用
golang.org/x/net/netutil.LimitListener，它会在Accept失败时返回net.ErrClosed，http.Server能正确处理并记录日志 - 典型配置：
server := &http.Server{...}; server.ListenAndServe()前，把 listener 包一层：listener = netutil.LimitListener(listener, 50)
真实部署时容易忽略的 OS 层瓶颈
Go 层限流再严，如果操作系统没配好，照样崩。三个最常被跳过的点：
-
/proc/sys/net/core/somaxconn过小（默认常为 128），导致大量连接在内核队列排队，表现为客户端connection refused或高延迟——应调至 4096+ - 文件描述符上限：
ulimit -n默认常为 1024，而每个连接至少占 1 个 fd，限流后连接存活时间变长，fd 更易耗尽——需设为 65536 或更高 - Linux 的
vm.swappiness=1（而非默认 60），避免频繁 swap 导致 I/O 延迟毛刺，尤其当限速 reader 占用大量内存缓冲区时
这些不是 Go 代码能绕过的，漏掉任何一个，限流逻辑都可能在压力下失效。
