Go strconv.ParseInt 资源没有释放为什么

strconv.ParseInt 没有需要手动关闭的文件、连接或句柄，也没有 Close 或 Free 调用。批量解析后看到“资源没释放”，先确认观察的是累计分配、当前堆内存还是进程内存，再检查业务是否长期保存输入、结果或错误对象。解析错误中的 NumError.Num 包含输入文本，错误缓存不断增长也会让这些数据一直被业务持有。

官方地址：https://pkg.go.dev/strconv#ParseInt

先建立基线：调用次数不等于留存数量

设想一个数字导入接口：正常数据直接统计，失败的数据则被追加到全局错误列表。错误比例增加后，进程内存也增加，于是问题被归因于 ParseInt 没有释放资源。这里是用于推演的原创场景，不是一次实测事故。

先记录四个数字：每批输入条数、失败条数、错误列表长度和当前仍被保存的批次数。假设一批有 10000 条失败输入，旧方案保留全部错误对象，那么这一批就保留 10000 条错误引用；如果连续批次从不淘汰，留存数量还会累加。这个计数能直接从业务策略推导，但不能直接换算成准确内存字节数。

内存指标文档：https://pkg.go.dev/runtime#MemStats

假设要落到引用关系，而不是补一个释放函数

ParseInt 的职责是按指定进制和位宽解析字符串，返回整数与错误。失败时可以得到 NumError，里面有失败函数名、输入文本和原因。业务把这个错误保存在 map、切片或异步队列里，就延长了错误及其关联文本的生命周期。

因此应追查“谁还在持有”，而不是寻找不存在的释放接口。普通 Go 对象变得不可达之后，回收时机由运行时决定；局部变量被赋 nil 也不会清除其他容器中的引用。与此同时，不要把文档中的 Num 字段推演为某个版本必然保留整块上游读取缓冲：具体字符串存储和分配策略不是这里要依赖的接口保证。

改动点：保留分类摘要，并限制样本数量

如果界面只需要知道哪一条失败、是什么类型，可以保留序号和固定分类，不保存完整错误及输入原文。下面方案把错误样本限制为 16 条，仍统计全部成功与失败数量；超出样本上限的失败只计数。是否需要保存完整失败文件，应由另一套有容量与保留期的业务方案决定。

package main

import (
    "errors"
    "fmt"
    "strconv"
)

type Failure struct {
    Row  int
    Kind string
}

type Report struct {
    Accepted int
    Rejected int
    Samples  []Failure
}

func summarize(tokens []string) (Report, error) {
    const maxRows = 10000
    const maxTokenBytes = 128
    const maxSamples = 16
    if len(tokens) > maxRows {
        return Report{}, fmt.Errorf("本批最多允许 %d 条输入", maxRows)
    }
    report := Report{Samples: make([]Failure, 0, maxSamples)}
    for i, token := range tokens {
        kind := ""
        if len(token) > maxTokenBytes {
            // 先限制单项输入，避免对超长文本构造完整解析错误。
            kind = "too-long"
        } else {
            _, err := strconv.ParseInt(token, 10, 32)
            if err == nil {
                report.Accepted++
                continue
            }
            // 固定十进制与位宽，分类后不把错误对象或原文留在报告中。
            switch {
            case errors.Is(err, strconv.ErrSyntax):
                kind = "syntax"
            case errors.Is(err, strconv.ErrRange):
                kind = "range"
            default:
                kind = "other"
            }
        }
        report.Rejected++
        if len(report.Samples) 

代码固定十进制和 32 位有符号范围。输入带空格不会被自动修剪；超出范围也作为失败计数，不使用错误返回时附带的整数作为成功数据。本文只需要统计，所以丢弃成功值；实际导入如果保存整数结果，同样要限制结果集大小。

长度限制是进入 ParseInt 之前的业务防线，不能消除上游已经为整份输入支付的内存成本。例子接收一个已有切片，调用方只要继续保存它，里面的原始字符串仍然存在。它改善的是报告的留存模型，不是把整个系统变成固定内存流式处理器。

怎样安排一组可比较的测量

将旧方案与摘要方案放在相同工具链、相同输入、相同错误比例和相同并发量下比较。分别记录每批耗时、每操作分配字节、每操作分配次数、批次结束后的错误记录数量，以及在一致 GC 观察条件下的堆快照。不要一边更换输入长度，一边把内存变化全部归因于代码修改。

想看分配压力时可使用 Go 基准测试的 benchmem 指标；想看仍被持有的对象时，应查看堆剖析中的存量视角，并追到持有者。测试夹具自身也可能保存输入，报告写入测试结果的位置也会影响对象是否仍可达。这些条件应一起记录。

本文没有执行压测，因此不提供 ns/op、B/op、RSS 降幅或“零分配”的数字。成功路径、错误路径、输入长度、编译器优化和业务包装都会影响实际结果。测量目标也不是证明某个函数绝不分配，而是判断增长来自短期分配压力还是持续留存。

可以直接推导的变化，与尚待测量的结果

固定四条示例输入按规则应为 1 条成功、3 条失败：bad 与带空格的 12 是语法类，2147483648 超出 32 位有符号范围。这是代码规则推导，不是运行日志。对 10000 条全部失败的受限输入，摘要方案仍会统计 10000 次失败，但最多保留 16 条样本。

16 条是样本数上限，不是进程对象数、总分配量或总内存上限。若调用方将每批报告继续无限追加，系统仍会增长；若异步日志队列没有容量控制，搬走错误对象也只是换了一个留存地点。报告生命周期、批次数与队列长度需要一起受控。

哪些情况要在解析函数之外处理

如果上游打开了文件、HTTP 响应或数据库游标，关闭责任属于取得这些资源的调用层，ParseInt 不会替它关闭。只看解析函数附近的堆栈，不能排除上游资源管理问题。外部句柄泄漏与普通堆对象留存也要分别观察。

HeapAlloc 包含尚未回收的不可达对象，TotalAlloc 则是累计量，本来就不会因为对象释放而下降。RSS 与 Go 堆指标也不是同一个口径；回收可用内存和操作系统立即看到驻留量下降之间不能画等号。不要在每次解析后强制 GC，把业务引用问题变成更高的回收开销。

垃圾回收说明：https://go.dev/doc/gc-guide

把 err 赋成 nil，为什么内存没有马上下降？

其他容器可能还持有同一错误或相关输入，而且不可达与实际回收并不同步。先查容器引用和批次保留策略，再解释指标。

把错误变成 err.Error() 保存，会更好吗？

完整字符串仍可能很大，也仍可能无限累积。需要的是有界且必要的信息，而不是仅更换缓存的类型。

能承诺 ParseInt 成功时零分配吗？

不要把特定版本或写法的测量结果扩大成通用承诺。使用真实调用路径测量，并区分解析、输入构造、日志和结果保存的成本。