go进程卡在1024文件描述符限制，是因为启动时继承shell软限制且不感知后续ulimit变更；systemd服务需显式配置limitnofile，硬限制不足时软限制无法提升，syscall.setrlimit仅在main开头早于fd分配时有效。
Go 程序在单机承载大量长连接（如 WebSocket、gRPC stream、HTTP/2 backend）时，常卡在 Too many open files，不是内核“锁死”，而是进程级文件描述符限制被提前耗尽——ulimit -n 默认 1024 是真瓶颈，fs.file-max 通常远未触顶。
为什么 ulimit -n 改了但 Go 进程还是卡在 1024？
Go 进程启动时继承 shell 的软限制（soft limit），且不会自动感知后续 ulimit -n 的变更。即使你临时执行了 ulimit -n 65536，若 Go 程序已在该 shell 启动前运行，它仍卡在旧值；若用 systemctl start 启动，则完全绕过 PAM limits，/etc/security/limits.conf 对它无效。
-
cat /proc/<pid>/limits | grep "Max open files"</pid>查真实生效值，别信ulimit -n当前 shell 输出 - systemd 服务必须显式配置
LimitNOFILE=65536在[Service]段，否则无视limits.conf - 硬限制（hard limit）低于目标值时，软限制无法设高：先查
ulimit -Hn，再决定是否需改limits.conf或 systemd 配置
Go 程序里调用 syscall.Setrlimit 有用吗？
有用，但仅限于程序启动早期、尚未打开大量 fd 之前。一旦进程已接近软限制上限，syscall.Setrlimit 可能失败（operation not permitted），尤其当硬限制未同步提升时。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 必须在
main()开头立即调用，早于任何net.Listen、http.Server启动或 goroutine 创建 - 参数
Cur和Max建议设为相同值（如 65536），避免运行时因软限不足触发降级 - 该调用不解决句柄泄漏，只放宽上限——若连接数持续增长且不回收，迟早再次打满
HTTP 客户端长连接导致句柄堆积的典型场景
Go http.Client 默认启用 keep-alive，后端服务若未正确响应 Connection: close 或服务端主动断连，连接会滞留在 ESTABLISHED 或 CLOSE_WAIT 状态，Transport 连接池持续持有 fd 不释放。
- 高频短请求 + 默认 Transport → 大量 idle 连接堆积在
IdleConnTimeout之前 - 后端服务异常（如挂起、TCP RST 未发）→ 连接卡在
TIME_WAIT或CLOSE_WAIT，fd 不归还 - 修复方向：显式配置
Transport，例如MaxIdleConns: 100、MaxIdleConnsPerHost: 100、IdleConnTimeout: 30 * time.Second - 调试时加
lsof -p <pid> | grep ':<port>' | wc -l</port></pid>看特定端口连接数，比总 fd 更准
真正容易被忽略的点
很多人调大了所有限制、重写了 Transport，但忘了 Go 的 net.Conn 实现依赖底层 socket，而 socket 创建失败时错误日志常被吞掉——accept 返回 EMFILE 时，http.Server.Serve 默认静默丢弃连接，不报错也不打日志，只会表现为“部分客户端连不上”，排查时极易误判为网络问题。
务必在 http.Server 启动后加健康检查逻辑，定期调用 syscall.Getrlimit(syscall.RLIMIT_NOFILE, &rl) 对比当前使用量，早于打满前告警。
