go程序“too many open files”源于系统fd限制，默认1024；需调高ulimit或systemd/容器配置；listener未close、http超时未设、conn deadline管理不当均导致fd泄漏。
Go 程序启动时就遇到 too many open files
这不是 Go 本身的问题，而是操作系统对单个进程能打开的文件描述符（file descriptor, fd）数量做了限制，默认通常只有 1024。Go 的 net.Listener、http.Server、甚至底层 epoll/kqueue 事件循环都依赖 fd，连接数一多就直接崩在 accept: too many open files。
必须在程序启动前调高软限制（soft limit），否则 runtime 无能为力：
- Linux 下用
ulimit -n 65536启动 Go 进程（注意：仅对当前 shell 及子进程生效） - systemd 服务需在 unit 文件中加
LimitNOFILE=65536，不能只靠ExecStart前加ulimit - 容器环境（如 Docker）要显式传
--ulimit nofile=65536:65536，镜像内ulimit不生效 - macOS 对
launchd有额外限制，需改/Library/LaunchDaemons/limit.maxfiles.plist并重启
net.Listen 之后没关 listener 导致 fd 泄漏
常见于热更新、优雅重启或测试代码里反复 net.Listen 却忘了 Close()。Go 的 Listener 是资源型对象，不关就不会释放 fd。
典型错误写法：
立即学习“go语言免费学习笔记（深入）”；
l, _ := net.Listen("tcp", ":8080")
// 忘记 l.Close()
正确做法：
- 监听器生命周期应与程序一致，全局复用一个
net.Listener，不要每次请求都重 listen - 若需动态切换端口或协议，务必先
l.Close()再新建，且确保关闭逻辑不会被 panic 中断（可用defer+recover或显式 error check） - 用
l.Addr().String()检查是否已绑定成功，避免静默失败后仍认为 listener 有效
HTTP Server 没设 ReadTimeout/WriteTimeout 引发连接堆积
默认情况下 Go 的 http.Server 对连接不设超时，慢客户端、网络抖动、恶意空连接都会让 goroutine 和 fd 长期挂起，fd 数缓慢爬升直至打满。
关键配置项（必须显式设置）：
-
ReadTimeout：从读取 request header 开始计时，防止慢速 HTTP 攻击 -
WriteTimeout：从 response.WriteHeader 开始计时，防止大响应卡住 -
IdleTimeout：控制 keep-alive 连接空闲多久后关闭（比KeepAlivePeriod更可靠） - 别依赖
http.DefaultServeMux，自定义http.Server实例并完整配置 timeout
示例：
srv := &http.Server{
Addr: ":8080",
Handler: myHandler,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 30 * time.Second,
}
用 net.Conn.SetDeadline 时没覆盖所有读写路径
如果你绕过 http.Server 直接用 net.Listener.Accept() 处理连接（比如做自定义协议），必须手动管理每个 net.Conn 的读写 deadline，否则单个死连接就能吃掉一个 fd。
容易漏掉的地方：
- 只设了
SetReadDeadline，但业务逻辑里有阻塞写（如大文件上传未分块），导致写永久挂起 - deadline 时间设成固定值（如
time.Now().Add(30*time.Second)），但连接存活期间未刷新，导致中途就断连 - 在 goroutine 里处理 conn 时，panic 后没 defer 关闭 conn，fd 泄漏
- 使用
bufio.Reader或bufio.Writer时，底层仍依赖原始 conn 的 deadline，需在每次Read/Write前重置
实际压测时，fd 使用量不是线性增长的——它和连接生命周期、错误处理健壮性、超时策略粒度强相关。最隐蔽的泄漏往往发生在 recover 逻辑缺失、defer 位置错位、或日志里吞掉 close 错误的地方。
