http.Server需显式配置超时与连接复用：ReadTimeout/WriteTimeout设5–10秒，IdleTimeout设30–60秒以复用连接，MaxHeaderBytes防内存耗尽。
用 http.Server 配置超时与连接复用
默认的 http.Server 没有设置读写超时，容易因慢客户端或网络抖动拖垮整个服务。连接不复用则每次请求都重建 TCP+TLS，显著增加延迟。
关键配置项必须显式设置：
-
ReadTimeout和WriteTimeout控制单次请求/响应耗时上限（建议 5–10 秒） -
IdleTimeout决定空闲连接保持多久（推荐 30–60 秒），配合客户端Keep-Alive复用连接 -
MaxHeaderBytes限制请求头大小，防内存耗尽（如设为1 即 1MB） - 禁用
HTTP/1.1的Connection: close行为，确保服务端返回Connection: keep-alive
server := &http.Server{
Addr: ":8080",
Handler: mux,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 60 * time.Second,
MaxHeaderBytes: 1 << 20,
}避免在 HTTP handler 中做同步阻塞操作
Go 的 HTTP server 是基于 goroutine 的，但一个 handler 里调用 time.Sleep、未加 context 控制的数据库查询、或同步文件读写，会直接卡住该 goroutine，堆积请求队列，提高 P95 延迟。
常见陷阱：
立即学习“go语言免费学习笔记（深入）”；
- 没传
ctx给下游调用（如db.QueryRowContext），导致超时无法中断 - 用
log.Printf打印大结构体，触发反射和字符串拼接，CPU 毛刺明显 - 在 handler 里启动无缓冲 channel 或调用
sync.WaitGroup.Wait等待未知时长
正确做法是：所有 I/O 操作必须带 context.WithTimeout，日志只打关键字段，大对象序列化前先判断是否开启 debug 模式。
启用 HTTP/2 与压缩（gzip / zstd）
HTTP/2 默认启用（Go 1.6+），但前提是使用 TLS —— 如果走纯 HTTP（http://），net/http 会自动降级到 HTTP/1.1，失去多路复用和头部压缩优势。
压缩方面：gzip 内置支持，但需手动包装 ResponseWriter；zstd 压缩率更高、解压更快，但需第三方库（如 github.com/klauspost/compress/zstd）。
- 不要对小响应（如 <1KB JSON）压缩，反而增加 CPU 开销和传输字节数
- 避免对已压缩资源（
.jpg、.png、.woff2）重复压缩 - 用
Content-Encoding+Vary: Accept-Encoding告诉 CDN 和浏览器可缓存不同编码版本
用 http.NewServeMux 替代全局 http.DefaultServeMux
全局 http.DefaultServeMux 是包级变量，多个模块注册路由时可能冲突（比如两个 init() 函数都调用 http.HandleFunc），且无法单独测试或替换中间件。
更严重的是：它不支持子路径挂载、无法统一加 CORS / 日志 / panic 恢复等中间件，导致逻辑分散、调试困难。
- 始终用
http.NewServeMux()创建独立实例 - 路由注册顺序影响匹配结果（最长前缀优先），避免
/api/users被/api提前捕获 - 静态文件用
http.FileServer+http.StripPrefix，别用http.ServeFile，后者不支持目录索引且易路径穿越
mux := http.NewServeMux()
mux.Handle("/static/", http.StripPrefix("/static/", http.FileServer(http.Dir("./static/"))))
mux.HandleFunc("/api/users", usersHandler)真正影响延迟的，往往不是算法复杂度，而是连接生命周期管理、context 传递是否彻底、以及是否误把“能跑通”当成“适合生产”。尤其在高并发下，一个没设 IdleTimeout 的服务，可能撑不过一次爬虫扫描。
