百万级HTTP连接撑不住的根本原因是默认阻塞I/O模型下每个Keep-Alive连接独占goroutine和fd，且未设Read/Write/Idle超时及MaxHeaderBytes，导致fd与内存指数级耗尽。
百万级 http 连接本身不会直接导致“句柄泄露”，但默认配置下必然引发文件描述符（fd）和内存的双重耗尽——根本原因不是并发量大，而是每个连接长期驻留且未受控释放。
为什么 net/http.Server 默认行为必然撑不住百万连接
标准 http.Server 是阻塞 I/O 模型，每个活跃的 Keep-Alive 连接会独占一个 goroutine 和一个底层 net.Conn，而后者绑定一个操作系统 fd。关键点在于：
-
ReadTimeout/WriteTimeout不设 → 慢请求或慢响应让 goroutine 和 fd 无限期挂起 -
IdleTimeout不设 → 空闲连接永不关闭，netstat -an | grep ESTABLISHED | wc -l会线性上涨 -
MaxHeaderBytes不限 → 单个恶意 header 可吃掉数 MB 内存，100 万连接放大攻击面 - HTTP/2 默认启用 → 每个 stream 复用连接但不减少 fd 总数，反而增加内存上下文开销
结果就是：fd 耗尽报 accept: too many open files，cat /proc/PID/status | grep VmRSS 显示 RSS 持续突破 3GB，runtime.ReadMemStats().HeapInuse 居高不下。
必须显式覆盖的四个超时参数
这不是“可选优化”，而是百万连接的前提条件。漏掉任意一项，资源就会指数级累积：
-
ReadTimeout: 15 * time.Second—— 防止上传卡住、body 读取阻塞 -
WriteTimeout: 15 * time.Second—— 防止 handler 生成响应过慢或客户端接收停滞 -
IdleTimeout: 60 * time.Second—— 最关键，强制空闲连接在 60 秒后关闭，避免 ESTABLISHED 堆积 MaxHeaderBytes: 64 （即 64KB）—— 限制单次请求头大小，防 DoS
注意：KeepAlivePeriod 已被弃用；ConnState 回调可用于统计连接状态，但不能替代超时控制。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
sync.Pool 复用 buffer 和 decoder 的坑
高频分配 []byte、json.Decoder 是 GC 主力军，但乱用 sync.Pool 反而加重压力：
- Get 后没调
Reset()→ 上次残留数据触发后续扩容，实际内存更高 - 把含指针字段的 struct（如带
map或chan）塞进 Pool → GC 扫不到，隐性泄漏 - 命中率低（
Get()经常返回nil）→ 白加 mutex 开销，go tool pprof -alloc_objects会暴露这点 - 正确姿势：
var jsonDecoderPool = sync.Pool{New: func() interface{} { return json.NewDecoder(nil) }}，使用时dec := jsonDecoderPool.Get().(*json.Decoder); dec.Reset(r.Body)，退出前jsonDecoderPool.Put(dec)
绕过 http.Serve 的连接接管是硬门槛
真要压到百万级，http.Server.Serve() 的封装层必须放弃。它内部对每个 conn 启一个 goroutine，无法规避栈和缓冲区固定开销。可行路径只有：
- 自己监听
net.Listener，用net.Conn.SetReadDeadline+bufio.Reader手动解析 HTTP 报文 - 复用
net.Conn底层 fd，配合epoll/kqueue（通过golang.org/x/sys/unix）做事件驱动 - 用
github.com/valyala/fasthttp替代标准库 —— 它不为每个请求启 goroutine，而是复用 worker goroutine + 固定 buffer 池
别信“调大 ulimit 就能扛住”的说法。ulimit 只是延缓崩溃，不是修复逻辑缺陷；真正瓶颈永远在连接生命周期管理是否闭环。
