os.File 必须显式调用 Close() 才能释放文件描述符，GC 不会自动回收；未关闭会导致 fd 泄露，触发 “too many open files” 错误。
为什么 os.File 没 Close() 就会泄露文件描述符
Go 程序里每打开一个文件、监听一个端口、启动一个子进程，底层都会分配一个文件描述符（fd）。操作系统对每个进程的 fd 数量有限制（通常默认 1024 或 65536），一旦耗尽，open、listen、os.Open 等调用就会返回 "too many open files" 错误——这不是 Go 层面的 panic，而是 syscall 失败，极难现场定位。
根本原因在于：Go 的 os.File 不是纯内存对象，它持有一个系统级 fd 句柄；GC 不会自动回收 fd，必须显式调用 Close()。哪怕 os.File 变量超出作用域，只要没 Close()，fd 就一直占用。
- 常见漏关场景：
os.Open后直接return忘了Close；defer f.Close()写在错误分支之后；io.Copy出错时提前返回但没关源/目标文件 - 子进程更隐蔽：
exec.Command启动后若未调用cmd.Process.Wait()或cmd.Wait()，其 stdio 管道 fd 也不会释放 - HTTP server 的
http.FileServer本身会自动关闭响应体，但自定义 handler 中手动os.Open文件并写入ResponseWriter时，仍需自己关
用 runtime.ReadMemStats 和 /proc/self/fd 双路监控 fd 使用量
单靠统计 os.File 对象数量没意义——GC 可能还没运行，且无法区分已 Close 和未 Close 的实例。真正可靠的指标只有两个：当前进程实际打开的 fd 数（/proc/self/fd 目录项数），以及历史峰值（用于趋势判断）。
建议同时采集：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
runtime.ReadMemStats虽不直接暴露 fd，但能获取 GC 触发频率和堆增长趋势——fd 泄露常伴随 goroutine 泄露，导致内存持续上涨，可作为辅助信号 -
filepath.Glob("/proc/self/fd/*")或直接filepath.ReadDir("/proc/self/fd")（Go 1.16+）统计当前 fd 数量，注意过滤掉.和.. - 避免用
ls -l /proc/self/fd | wc -l这类 shell 命令，fork 开销大且不可靠
示例采集逻辑：
func countFDs() (int, error) {
entries, err := os.ReadDir("/proc/self/fd")
if err != nil {
return 0, err
}
return len(entries), nil
}
在关键路径注入 file.FD() 记录与生命周期校验
被动监控只能发现“已经泄露”，要定位源头，得在创建时打标记。Go 标准库的 os.File 提供 FD() 方法返回底层 fd 整数，可在 os.Open、os.Create、net.Listen 等调用后立即记录 fd 和调用栈。
- 用
map[uintptr]*fdInfo缓存活跃 fd，fdInfo包含createdAt time.Time和stack string（用debug.Stack()截取前几行） - 每次调用
(*os.File).Close()时，从 map 中删除对应 fd —— 注意：Close()成功后 fd 值变为-1，可用此判断是否已关 - 定时扫描 map 中存活超 5 分钟的 fd，触发告警并打印原始栈，精准定位未 Close 的代码行
- 不要依赖
Finalizer：它不保证何时运行，且 fd 可能已被复用，Finalizer回调里再查FD()会返回无效值
告警阈值设为软限制的 70% 而非硬限制
Linux 的 ulimit -n 是 per-process fd 上限，但内核实际分配时会有缓冲和保留，真正失败点往往低于该值。更稳妥的做法是读取 /proc/self/limits 解析 Max open files 行，取 soft limit 值。
- 硬限制（hard limit）通常不可突破，软限制（soft limit）才是进程实际受控的上限
- 告警阈值设为 soft limit 的 70%，留出 30% 缓冲给突发流量或短时 spike
- 避免每秒轮询：fd 增长通常是缓慢泄漏，10 秒采样一次足够；突增则可能来自批量操作，需结合业务日志交叉分析
- 告警渠道优先走内部 metrics 上报（如 Prometheus 的
process_open_fds），而非邮件——高频 fd 抖动容易淹没真问题
真正麻烦的是那些只在高并发下才暴露的泄漏：比如每秒处理 1000 个文件上传，每个漏关 1 个 fd，10 秒就耗尽。这种必须靠上线前压测 + 实时 fd 监控联动才能捕获。
