Go 服务报 too many open files 怎么办：从 FD 增长定位到修复与回退

订单服务的错误率从低位突然爬到3%，日志里不断弹出 too many open files。这时候很多人第一反应就是把进程打开文件限额调大，但这么做通常只是给资源泄漏多续了一点运行时间。先确认FD（文件描述符）是不是只涨不跌完全不回落，再把持续增长的对象归类到HTTP响应、普通文件、数据库结果集或连接这几个常见大类，后续的修复才不会变成盲目的堆资源扩容。

报警出现后，先判断FD是峰值波动还是真泄漏

一次后台导入任务或者突增的流量尖峰，都会让FD数值暂时走高，这个现象本身不能直接判定有问题。真正需要警惕的信号是：流量已经完全回落，进程打开的FD还是在按近似固定的斜率持续增长，随后新建连接、读取配置或者写日志的操作开始随机报错。

Linux容器环境里可以先看一小段时间窗口的FD数量变化，再逐个核对每个描述符指向的实际对象。不要只截一次观测结果就下结论，间隔几十秒采样两三次，更容易看清楚真实的增长趋势。

pid=$(pgrep -f order-api | head -n 1)
ls /proc/$pid/fd | wc -l
lsof -p $pid | awk 'NR > 1 {print $5}' | sort | uniq -c

把增长对象分成三类，定位效率会高很多

先别急着在全量代码里全局搜 Close。从 lsof 的类型和目标名称入手，通常就能把排查范围收得很小：大量 TCP 大概率是下游HTTP或者数据库连接泄漏，重复出现的日志、临时文件或者证书路径更像是普通文件句柄没释放，数据库相关的对象就回到 Rows 的生命周期做逐段检查。

线上故障处置的时候我会先临时暂停最容易放大问题的批量接口，同时保留一小段异常窗口里的FD数量、错误计数和关联调用路径。这样哪怕临时限流让服务恢复了正常，后面也能明确知道是哪一类资源在持续占用，不会最后只留下一句“重启之后就好了”的无头结论。

HTTP客户端：读完内容也要记得关闭响应体

标准库的HTTP文档明确要求调用方，用完响应之后必须关闭body。把关闭动作放在拿到成功响应的下一行，就能覆盖后续JSON解析失败、状态码提前返回等各种异常分支。

func loadOrder(ctx context.Context, client *http.Client, url string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }

    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        return nil, fmt.Errorf("下游状态码: %s", resp.Status)
    }
    return io.ReadAll(resp.Body)
}

这里也别把每次请求都新建一个 http.Client 当成通用补救方案。客户端和Transport本身就适合全局复用，真正要注意的边界是请求完成后让响应体能正确归还连接池。如果业务逻辑只需要读取body的一部分内容，仍然要按照客户端语义把读取和关闭的策略设计完整。

文件和查询结果：循环里别把释放动作拖到函数末尾

批量处理场景里最隐蔽的错误写法，就是在一个很长的循环里不断打开文件或者查询结果，再把所有的释放动作全部推迟到外层函数返回的时候才执行。把单次处理逻辑封装进一个小函数，资源就会在每一轮循环结束的时候自动归还。

func readOne(path string) ([]byte, error) {
    f, err := os.Open(path)
    if err != nil {
        return nil, err
    }
    defer f.Close()
    return io.ReadAll(f)
}

for _, path := range paths {
    data, err := readOne(path)
    if err != nil {
        return err
    }
    _ = data
}

sql.Rows 也应该遵守相同的原则：遍历完结果之后及时关闭，所有提前返回的分支都不能绕过关闭动作。标准库在读到结果集尾部的时候会自动关闭Rows，但代码逻辑不该把“恰好能完整遍历全量数据”当成唯一保障，尤其是中途校验失败、分页提前停止或者调用方主动取消请求的场景。

修复前后先做小流量对照，再决定要不要改限额

找到资源释放的缺口之后，先在一台低流量的实例上做修复，用同一批请求做对照验证。期望看到的效果是：压测或者流量回放期间FD随着并发起伏变化，停止流量之后数值能回到之前的稳定基线，错误计数也不再和FD上升同步出现。只有确认这个趋势成立，才适合把修复扩到更多实例上。

把系统或者容器的打开文件上限调高确实能争取故障处理时间，但它本身不能修复遗漏释放的根因。如果先把限额调大，泄漏会持续更久，占用更多内存和连接资源，等真正触顶的时候故障现场反而更难还原。需要调整限额的时候，把它当成普通容量配置操作处理：记录当前基线、峰值、预留余量和变更后的告警阈值。

回退和告警别只盯单个数值阈值

如果修复之后错误率还在继续升高，先回退刚改动的调用封装或者批任务并发策略，同时保留所有异常样本方便后续追溯。不要在同一个时间窗口里同时替换HTTP客户端、调整连接池参数、提高限额和扩大并发量级，改动变量太多的时候，根本没法确认是哪一步操作让趋势好转或者恶化。

告警至少要配置三条规则：FD使用量或者占比、FD的增长斜率、和它关联的下游错误率。前两条用来提前发现泄漏趋势，第三条能帮值班人员快速判断故障是不是已经对用户产生影响。对于长期运行的常驻服务，再加一条“流量回落后N分钟数值仍未回到基线附近”的趋势检查，往往比单一的绝对阈值更早发现潜在问题。

上线前留一份资源释放复查清单

• 每个 http.Client.Do 成功返回之后，有没有在同一个作用域内安排好 resp.Body.Close()？
• 打开文件、获取 sql.Rows、创建临时对象之后，所有提前返回的分支路径都能保证正常释放吗？
• 长循环逻辑有没有把资源释放限制在单次迭代范围内，而不是拖到整个任务全部结束？
• 压测结束之后，FD能不能在预期时间内回落，而不是只确认接口返回200状态码？
• 限额变更、并发变更和资源释放修复有没有拆成可以独立回退的多个改动项？

延伸问答

FD数量高就一定是泄漏吗？

不一定。高并发场景、连接复用机制、批量文件处理都可能形成短时峰值。核心判断点是观察压力消退后的回落情况，以及同一类对象是不是在持续累积不释放。

能不能直接调高ulimit参数？

可以作为临时缓冲手段或者容量规划的一部分，但不该替代根因定位。先把增长来源找出来，再评估当前限额是不是确实低于业务正常运行的峰值需求。

为什么业务请求已经正常返回，FD还会继续增长？

业务调用返回不等于响应体资源已经正常归还。漏掉关闭逻辑、执行路径只走到错误分支、或者把读取逻辑放到了没法正常收尾的后台流程里，都可能留下资源占用。

数据库遍历到末尾还需要显式关闭Rows对象吗？

完整遍历结果集会触发自动关闭，但显式关闭仍能覆盖提前停止、错误处理和后续代码改动造成的非完整遍历路径，代码的边界逻辑会更清晰。

这类故障从来不会靠一次重启就彻底解决。把FD的变化趋势、资源类型和释放路径串到同一条排查链路里，下次再看到相关报错的时候，团队就能从已有的观测证据出发定位，而不是上来就先做扩容操作。