Go time.After 在 for-select 循环里每秒 5 万次的内存泄漏 3 天复盘:18 小时准时 OOM + ticker / NewTimer.Reset / Go 1.23 三套正解

2026 年 2 月,我们一个用 Go 1.22 写的 event-fanout 服务被运维拎出来报警:这是个把上游 Kafka 消息按 tenant 维度做扇出 + 限流 + 重试投递的中间件,日均吞吐 4.2 亿条。问题是服务跑了大约 18 小时后,RSS 从启动时的 220MB 一路涨到 11.6GB,最终被 K8s OOMKilled;重启后 18 小时左右又是一样的剧本,稳定得像闹钟。

3 天的排查最终把根因锁定在一个所有 Go 开发者都用过、几乎所有教程都"无害示范"过的写法上:time.After(d) 在 select { for {} } 循环里用。表面上每次循环都会"重新创建一个定时器",但底层 runtime 不会因为你 select 走了别的 case 就回收掉那个 timer——它必须在 d 时间过去之后才能进入 GC 视野。我们的 fanout 主循环每秒大约触发 5 万次 select,每次都会留下一个 30 秒后才能回收的 timer,叠加起来就是常驻 150 万个未到期 timer + 它们引用的 channel + closure,堆稳稳地往上爬。

故障背景:event-fanout 的架构与吞吐

先讲清楚 event-fanout 在做什么,否则后面看 timer 累积量没有体感。架构上它是一个 Kafka consumer + 多个下游 producer 的桥:

核心逻辑大约 80 行,关键就在每个 tenant worker 的主循环——从一个 tenant 专属的 buffered channel 读消息,做规则过滤,做限流(token bucket),做重试投递。简化后大概长这样,这就是埋雷的源头:

// tenant worker 的简化版本(这是 BUG 版本)
func (w *TenantWorker) Run(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            return
        case msg := <-w.inbox:
            w.dispatch(msg)
        case <-time.After(30 * time.Second):
            // 30 秒没消息就刷一次内部统计
            w.flushMetrics()
        }
    }
}

这段代码很经典——很多 Go 教程、博客、StackOverflow 高赞都是这么写的。看起来无害:一个 worker goroutine,select 三路,30 秒兜底刷指标。问题在于:当 inbox 持续有消息时,你以为 time.After 那一路从来没"用上",但它每次都被创建出来了。

事故时间线

第一轮排查:被 channel 堆积带偏

第一反应是 inbox 堆了——直觉上"内存涨"等于"队列堆"。我们给 inbox channel 加了长度指标:

// 给每个 tenant 的 inbox 加长度指标
var inboxLength = prometheus.NewGaugeVec(prometheus.GaugeOpts{
    Name: "fanout_inbox_length",
    Help: "current pending msgs in tenant inbox",
}, []string{"tenant"})

// 在 worker 里每秒上报一次
go func() {
    t := time.NewTicker(time.Second)
    defer t.Stop()
    for {
        select {
        case <-ctx.Done():
            return
        case <-t.C:
            inboxLength.WithLabelValues(w.tenantID).Set(float64(len(w.inbox)))
        }
    }
}()

抓了一晚上数据,inbox 长度平均 4,P99 也只有 47,基本随到随处理,完全不存在堆积。这就把"队列堆"这个最容易的解释否掉了。

第二轮排查:goroutine 泄漏?

第二个怀疑是经典 Go 内存涨怀疑——goroutine 泄漏。挂 pprof:

go tool pprof -http=:8080 http://localhost:6060/debug/pprof/goroutine
# 看到 goroutine 数:启动时 ~3850,跑了 12 小时还是 ~3855
# top 显示 99% goroutine 卡在 chan receive,这就是 tenant worker 自己在等消息,正常状态

goroutine 数稳得不能再稳,根本没泄漏。这时候我们犯了 Go 内存排查最容易犯的错:看到 goroutine 不泄漏,就以为"对象引用关系正常",转而怀疑 GC 压力。其实 goroutine 不泄漏不代表它们没有"持有大量未回收对象"——尤其是 timer 这种 runtime 内部数据结构,根本不会出现在 goroutine 栈上。

第三轮排查:heap profile 锁定 time.NewTimer

抓 heap profile,这次看 alloc_space 而不是 inuse_space(因为我们要找的是"持续在分配"的源头):

curl -o heap.pprof http://localhost:6060/debug/pprof/heap?seconds=60
go tool pprof -top -sample_index=alloc_space heap.pprof | head -20

# 输出:
# Showing nodes accounting for 9.42GB, 89.31% of 10.55GB total
# flat  flat%   sum%       cum   cum%
# 6.71GB 63.6% 63.6%    6.71GB 63.6%  time.NewTimer
# 1.21GB 11.5% 75.1%    1.21GB 11.5%  runtime.makechan
# 0.84GB  8.0% 83.1%    0.84GB  8.0%  time.startTimer
# 0.32GB  3.0% 86.1%    0.32GB  3.0%  github.com/example/fanout.(*TenantWorker).dispatch

看到 time.NewTimer 占 63.6% 的 alloc_space 立马就清醒了。我们代码里没有直接调用 time.NewTimer——但 time.After 内部就是 NewTimer(d).C。再用 list 子命令定位调用栈,直接指向 tenant worker 的 select。

问题本质:time.After 在 for-select 里的真实行为

这里必须把 time.After 的 runtime 行为讲清楚,否则换成别的 timer API 也是踩坑。Go 标准库 time.After 的实现非常简单:

// src/time/sleep.go(标准库源码,简化)
func After(d Duration) <-chan Time {
    return NewTimer(d).C
}

func NewTimer(d Duration) *Timer {
    c := make(chan Time, 1)
    t := &Timer{
        C: c,
        r: runtimeTimer{
            when: when(d),
            f:    sendTime,
            arg:  c,
        },
    }
    startTimer(&t.r) // 把 timer 注册进 runtime 的 timer heap
    return t
}

关键事实有三条:

1. time.After 没有暴露 *Timer,所以你拿不到 Stop();
2. timer 注册进 runtime 的 4-heap(P 本地)后,只有等到 when 到点 + channel send 完成,才会从 heap 移除并允许 GC;
3. 即使你 select 没走 time.After 那一路,这个 timer 也不会被取消——它就在那等 30 秒,30 秒之内一直占着 timer heap + 一个 buffered channel + closure。

所以在 for-select 里每秒触发 5 万次 select 的场景下,如果 time.After(30 * time.Second) 永远跑不到那一路(因为消息源源不断),你就每秒往 runtime 里塞 5 万个 30 秒后才能 GC 的 timer,稳态就是 5 万 × 30 = 150 万个未到期 timer。每个 timer 大概占 100-200 字节,加上 channel 和 closure,放大到 GB 级太容易了。

整个故障的因果链画出来:

修法 1:time.After → time.NewTimer + 复用

最直接的修法是显式管理 timer:在 for 外面创建,在 for 里 Reset,select 走完那路就 Drain。改造后的 tenant worker:

// 正解版本:显式 timer + Reset,timer 只有一个
func (w *TenantWorker) Run(ctx context.Context) {
    timer := time.NewTimer(30 * time.Second)
    defer timer.Stop()

    for {
        // 每次循环前重置:先 Stop,再 drain channel(可能已经触发),再 Reset
        if !timer.Stop() {
            select {
            case <-timer.C:
            default:
            }
        }
        timer.Reset(30 * time.Second)

        select {
        case <-ctx.Done():
            return
        case msg := <-w.inbox:
            w.dispatch(msg)
        case <-timer.C:
            w.flushMetrics()
        }
    }
}

这版本只持有一个 timer 对象,内存占用从"5 万/s × 30s × 3800 tenant"压到"3800 个常驻 timer",降了五个数量级。但 Stop + drain + Reset 这三步操作有坑:

修法 2:Go 1.23+ 直接用 time.NewTimer 不需要 drain

这是一个值得 highlight 的版本演进。Go 1.23 改了 timer 实现:Reset 和 Stop 现在保证 channel 里不会残留事件,所以你可以省掉 drain 那段奇葩代码:

// Go 1.23+ 简化版本:Reset 前不需要 drain channel
func (w *TenantWorker) Run(ctx context.Context) {
    timer := time.NewTimer(30 * time.Second)
    defer timer.Stop()

    for {
        timer.Reset(30 * time.Second) // 不需要 Stop,不需要 drain
        select {
        case <-ctx.Done():
            return
        case msg := <-w.inbox:
            w.dispatch(msg)
        case <-timer.C:
            w.flushMetrics()
        }
    }
}

另外 Go 1.23 还把 timer 的 GC 行为改了:即使你不 Stop,timer 在到期前如果没人引用 *Timer,会被 GC 回收掉它的内部数据。所以严格说 Go 1.23+ 之后 time.After 在 for-select 里也"不会泄漏"了——但仍然推荐显式管理,因为分配速率仍然是问题,会让 GC 频繁触发。

修法 3:用 ticker 替代 for-select 里的兜底 timer

如果"30 秒没消息就刷一次"这个语义可以放宽成"每 30 秒固定刷一次"(我们的 flushMetrics 本来就是定期),那直接用 time.NewTicker 更干净:

// 用 ticker 把 metrics 刷新独立出来
func (w *TenantWorker) Run(ctx context.Context) {
    ticker := time.NewTicker(30 * time.Second)
    defer ticker.Stop()

    for {
        select {
        case <-ctx.Done():
            return
        case msg := <-w.inbox:
            w.dispatch(msg)
        case <-ticker.C:
            w.flushMetrics()
        }
    }
}

ticker 只创建一次,触发后自己重置下一次,语义完全无歧义。这是大多数 for-select 兜底场景下的最佳选择——除非你真的需要"每条消息之间间隔超过 N 秒才触发"的语义,那才用 timer.Reset。

修法 4:context.WithTimeout 不能这么用

这里要破除另一个误区。有些同事看到泄漏后第一反应是"用 context.WithTimeout 包一下不就行了":

// 反例:这不是解决方案
for {
    ctx2, cancel := context.WithTimeout(ctx, 30*time.Second)
    select {
    case <-ctx2.Done():
        w.flushMetrics()
    case msg := <-w.inbox:
        w.dispatch(msg)
    }
    cancel() // 这里有 cancel 但每次 for 都重新创建 ctx
}

这版本表面看起来"有 cancel",但 context.WithTimeout 内部也是用一个 timer 实现的,每次 for 都创建新 ctx 等同于每次创建新 timer——只不过这里我们调了 cancel() 所以它能立刻释放。如果忘了 cancel(),效果和 time.After 一样。这个写法不"省力",反而更容易出错(忘 cancel),也并不解决问题。

5 处历史泄漏点的统一改造

我们扫了仓库,发现 time.After 在 for-select 里的用法一共有 7 处:

grep -rn "time.After" --include="*.go" . | grep -v "_test.go"
# fanout/tenant_worker.go:42      bug A
# fanout/dispatcher.go:108         bug B
# retry/queue.go:55                bug C
# heartbeat/sender.go:23           bug D
# admin/poll.go:88                 bug E
# kafka/consumer.go:130            bug F(其实是一次性使用,不在 for 里,安全)
# ratelimit/refill.go:67           bug G

对照规则:

性能基准:改造前后的对比

我们在 staging 用 wrk2 模拟 4 倍生产负载,跑 8 小时:

修完之后 CPU 使用率直接降了 50%——之前居然有一多半 CPU 在帮 GC 扫 timer heap,这部分不算业务工作。

决策树:for-select 里该用哪个 timer API

引申:为什么 Go 标准库不直接禁止这种用法

很多人(包括我们事后)第一反应是:"这么容易出错的 API,为什么 time.After 还存在?" 这个问题在 Go 社区争论了多年,proposal 也提过好几次,最后维持现状的原因有三个:

1. 历史兼容性:Go 1.0 就有 time.After,大量代码依赖它(尤其是测试代码、一次性 timeout),改语义会破坏向后兼容;
2. 大多数场景下没问题:HTTP handler 里的 select { case <-time.After(5*time.Second): ... case <-ctx.Done(): ... } 这种一次性 wait 用 After 是完全合理的,处理完整个 handler 就结束了,timer 自然回收;
3. Go 1.23 改 runtime 解决了真正的"泄漏":1.23 之后即使你滥用 After,只要不引用 *Timer,内部数据可被 GC,所以"泄漏"严格来说不存在了,只是"分配速率高"。

但这并不意味着我们就该继续这么写——分配速率高就意味着 GC 频率高、CPU 浪费、heap 抖动,对线上服务都是实打实的成本。所以"显式管理 timer"仍然是 Go 服务端代码的最佳实践。

容易混淆的相关坑:context.WithDeadline 也是 timer

排查过程中我们顺带审了一遍跟时间相关的 API,发现 context.WithDeadline / WithTimeout 在某些场景也会有类似分配问题:

// 反例:per-request context 没 cancel
func (h *Handler) Serve(r *http.Request) {
    ctx, _ := context.WithTimeout(r.Context(), 2*time.Second)
    // 这里没接收 cancel,go vet 会报警
    h.doWork(ctx)
}

// 正解:必须接 cancel,defer cancel
func (h *Handler) Serve(r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
    defer cancel()
    h.doWork(ctx)
}

原理一样:WithTimeout 内部创建 timer,如果不 cancel,timer 要等到 timeout 到点才会回收。高 QPS handler 里这同样能堆出几百 MB 的 timer 对象。go vet 会报这个,务必把 vet 接进 CI。

我们立的 10 条 Go timer 工程纪律

1. for-select 里禁止 time.After:除非你能用数学证明每次循环都会走 timer 那一路。CI 加一条 lint。
2. 固定周期用 time.NewTicker,记得 defer ticker.Stop()。
3. 动态间隔用 time.NewTimer + Reset:Go 1.23+ 直接 Reset,1.22 及以下要 Stop + drain + Reset。
4. 所有 context.WithTimeout/WithDeadline 必须 defer cancel():go vet 帮你查。
5. Heap profile 看到 time.NewTimer 高分配立即怀疑这条规则:即使你代码里没直接调用 NewTimer。
6. RSS 周期性涨 + OOM 但 goroutine 不泄漏 → 强烈怀疑 timer / channel buffer。
7. 升级到 Go 1.23+:timer runtime 重写后 timer heap 性能 + GC 友好性都大幅提升。
8. 禁止在 hot path 用 fmt.Sprintf 拼 metric label:常见的辅助泄漏点。
9. 所有长生命周期 goroutine 必须可以被 ctx.Done() 关闭:select 第一路永远是 case <-ctx.Done(): return。
10. CI 接 go vet + staticcheck:这两条能扫出 7-8 成 timer 类问题。

跨语言比较:其他语言里有类似坑吗

结论:几乎所有语言都有类似设计——这是异步编程范式本身的特性,不是 Go 独有。其他语言之所以"踩坑率较低",通常是因为它们的 GC 更主动,或者 API 更难"无脑写错"(比如 Rust 强制处理 Future)。但只要你写出"循环里每次都创建一个未来某时刻才触发的对象"这种代码,内存压力一定会上去。

引申一:在生产复现的难度

这个 bug 写在最基础的 select 模式里,但在测试环境基本复现不出来。我们 staging 跑了大量集成测试都是绿的,因为:

1. 测试环境流量不够:CI 里 mock 出来的负载顶天 100 msg/s,稳态 timer 只有 100 × 30 = 3000 个,占用几 MB,根本看不出来;
2. 测试时长不够:绝大部分集成测试跑 5-30 分钟,远远到不了 RSS 起飞的拐点(我们生产环境也要 18 小时);
3. K8s limit 在测试环境通常宽松:staging Pod 给 32Gi limit 是常事,12GB 的中间态根本不触发 OOM 报警。

这就引出一个工程教训:负载测试必须按生产级流量 × 持续时长设计。我们事后给压测平台加了一个标准 profile:"性能基线测试 = 1.5x 峰值流量 × 24 小时 + 严格 limit",这个 profile 跑下来如果 RSS 不稳定,直接不让上线。

引申二:metric 设计也要避坑

修完 timer 之后我们又顺手审了 Prometheus 指标,发现还有第二个隐性内存涨——WithLabelValues 的 label 基数失控:

// 反例:label 用 user_id,基数无限大
var requestDuration = prometheus.NewHistogramVec(
    prometheus.HistogramOpts{Name: "request_duration"},
    []string{"user_id", "endpoint"}, // user_id 是动态的,百万级基数
)

// 正解:label 必须是有限枚举
var requestDuration = prometheus.NewHistogramVec(
    prometheus.HistogramOpts{Name: "request_duration"},
    []string{"tenant_tier", "endpoint"}, // tenant_tier 只有 free/pro/enterprise
)

Prometheus client 内部用 map 缓存每个 label 组合的 metric 对象,基数无限大就是无限大的 map,跟 timer 累积本质同源。我们加了一条 lint 规则:metric label 出现 id 字眼必须人工 review。

引申三:Go 调度器对 timer 的特殊处理

顺带说一下为什么"加 GOGC=50 反而 OOM 更快"。Go 调度器对 timer heap 有一个细节:P 在执行 goroutine 之前会先检查本地 timer heap,看有没有到期的。timer heap 越大,这个检查越慢。我们 timer heap 涨到 38 万时,P 每次调度前的检查开销翻倍——意味着相同 wall clock 内,业务 goroutine 跑的真 work 变少,GC 触发更频繁,内存分配速率反而升高(因为同样的业务请求要被 schedule 多次切换)。这是个反直觉的二阶效应:timer heap 大,不仅占内存,还拖慢调度。Go 1.23 把 timer 从 P 本地的 4-heap 改成全局 + 本地双层结构,部分缓解了这个问题。

引申:回头看那 18 小时为什么这么准

事后复盘,18 小时 OOM 的"准时性"让我们好奇:为什么不是随机时间?算了一下就明白了:

// 估算稳态 timer 数:5 万触发/s × 30s = 150 万 timer
// 每个 timer 占用:Timer struct(~64B) + runtimeTimer(~80B) + channel(~96B) + closure(~48B) ≈ 290B
// 稳态 timer 占用:150 万 × 290B ≈ 415 MB
// 但 Go heap 还有 fragmentation + GC overhead,实际 RSS 会 × 3-4
// 所以稳态 RSS 估计 ~1.6 GB

// 但实测 RSS 在涨到 12GB 才 OOM,差距来自哪?
// 答案是:每次 GC 之间的"未到期 timer"会比稳态多很多,
// 加上 channel 的 send 路径 + closure 持有的 *TenantWorker
// 整体放大系数大约 6-8 倍
// 直到 RSS 触达 limit(12GB)需要的时间:
// 12GB - 220MB ≈ 11.8GB,稳态净增速 ~170 MB/h
// 11.8GB / 170MB ≈ 69 小时(理论)
// 但 GC 把一部分回收回去,实际有效净增速大约 600 MB/h
// 11.8GB / 600MB ≈ 19.6 小时 ≈ 18 小时,基本对得上

能用数字算到这个程度,说明这个故障是确定性的,不是偶发。可惜上线时我们没有人意识到 for-select + time.After 的稳态成本——所有"5 万/s × 30s 留 150 万对象"这个数学,如果有人在 code review 时认真算一次,就不会埋这个雷。这件事让我们后来在 review checklist 里加了一条:任何引入新 select 循环的 PR,reviewer 必须问"如果触发频率乘以 timer 持续时间,稳态对象数是多少"。

引申四:Go 1.23 timer 重写的内部细节

顺带把 Go 1.23 timer runtime 重写的关键点讲清楚,这影响所有人未来的 timer 写法选择。1.22 及以下,timer 实现的核心问题有四个:

1. timer.C 是 buffered channel(cap=1):这意味着 fire 之后的 channel send 会成功(不需要 receiver),但你要么 receive 要么手动 drain;
2. Stop 返回 false 时,timer 可能已经"触发但未 send"或"已 send 待 receive":这两种状态用户代码需要处理,所以才有 Stop + drain 的范式;
3. timer heap 在每个 P 本地,跨 P 取消有 mutex 开销:高并发下成为热点;
4. 未到期 timer 持有 *Timer 引用,挡 GC:这是泄漏的根源。

Go 1.23 的重写:

升级 1.23 之后我们重新跑了一遍 baseline:同样的 BUG 版本代码(故意没改),18 小时不再 OOM,RSS 稳态在 3.8GB——还是高,但已经不会 K8s kill 了。这说明 1.23 的改造确实从 runtime 层缓解了滥用。但我们仍然把 7 处 time.After 全改成显式 timer,因为3.8GB 是 220MB 的 17 倍,只是没爆而已,不是没问题。

引申五:负载下的 GC 节奏与"伪稳态"陷阱

这次故障还教了我们一个反直觉的事:在生产观察"RSS 平稳"并不等于"内存健康"。BUG 上线前,我们做过一次 30 分钟的灰度,RSS 从 220MB 涨到 480MB 然后停在 480MB 上下波动,我们判定"稳态收敛了,可以全量"。事后才知道,30 分钟看到的是"GC 加快"和"分配速率"之间的瞬时平衡——分配速率是常数(5 万/s × 30s = 稳态 150 万对象),但 GC 触发由 GOGC × 已用 heap 决定,小 heap 时 GC 更频繁,看起来回收很积极。等 heap 涨到 GB 级后,GC 周期变长,这个平衡被打破,RSS 才开始抛物线式上涨。所以灰度时间至少要覆盖 1 个 GC 周期 × 几十倍,我们后来定的标准是任何性能相关 PR 灰度必须 ≥4 小时,且 RSS 必须经历过至少 3 次完整的 GC sawtooth。

引申六:Go runtime 内部 timer 4-heap 的结构

很多人对 timer heap 缺感觉,所以一直认为 "几十万个 timer 也就一点点"。这里把 1.22 之前的 4-heap 数据结构说一下:

合计每个 timer 大约 280-320 字节。150 万个 timer 直接占 ~450MB,GC 扫这个堆的根集开销也很大(每次 GC 都要遍历)。事故时我们看到 GC pause 在 100ms+ 级别波动,就是这个原因——CPU 一多半在做 GC 标记 timer 内部数据。

引申七:同类反模式的扫描方法

事故复盘后我们写了个简单的 ast 扫描工具,定时扫仓库找类似反模式。核心思路是用 Go 自己的 go/ast 包:

// scan-bad-timer.go:扫描 for-select 里的 time.After
package main

import (
    "go/ast"
    "go/parser"
    "go/token"
    "path/filepath"
)

func scan(root string) []string {
    var hits []string
    filepath.Walk(root, func(p string, info os.FileInfo, _ error) error {
        if filepath.Ext(p) != ".go" {
            return nil
        }
        fset := token.NewFileSet()
        f, _ := parser.ParseFile(fset, p, nil, 0)
        ast.Inspect(f, func(n ast.Node) bool {
            forStmt, ok := n.(*ast.ForStmt)
            if !ok {
                return true
            }
            // 检查 for body 里是否有 select,select 里是否有 time.After
            ast.Inspect(forStmt.Body, func(n2 ast.Node) bool {
                sel, ok := n2.(*ast.SelectStmt)
                if !ok {
                    return true
                }
                for _, c := range sel.Body.List {
                    if containsTimeAfter(c) {
                        hits = append(hits, fmt.Sprintf("%s: %v", p, fset.Position(c.Pos())))
                    }
                }
                return true
            })
            return true
        })
        return nil
    })
    return hits
}

这工具跑一次 monorepo 几分钟,直接生成可检视报告。我们接进了 PR check,任何 PR 引入新命中都需要 staff engineer 签字。半年下来一共拦了 4 次同类反模式,效果远超人肉 review。

引申八:常被遗漏的 time 相关高分配 API 清单

除了 time.After,Go 标准库还有几个 time 相关 API 在热点路径上会成为分配大户。我们顺便整理了一份"高分配 API 清单",在 PR review 时对照:

特别提醒 time.Tick——它返回的 channel 没有任何方式 stop,goroutine 一旦持有这个 channel 引用,这个 ticker 就和进程同生命周期。这比 time.After 还危险,因为后者 30 秒后 GC 还能介入,前者永远不会。Go 标准库自己的文档就警告"The underlying Ticker cannot be recovered by the garbage collector; it 'leaks'"。我们的代码规约里直接禁掉了 time.Tick。

总结

这次故障表面是 time.After 一行代码的写法问题,本质是对 Go runtime 内部数据结构生命周期的认知缺失——timer 不是"用完即扔的轻量对象",它在到期之前会牢牢占着 runtime 的 timer heap。任何高频 for-select 循环里的 time.After,本质上都是把"未来 N 秒"的对象都堆在内存里。

修法的核心三条:固定周期用 ticker、动态间隔用 NewTimer+Reset、Go 1.23+ 优先升级。比这更重要的是,养成"想清楚每次循环新生对象的稳态数量"的习惯——这个习惯不仅救 timer,也救 channel buffer、map 缓存、closure 引用。下一次你在 PR 里看到 for-select 加新 case,问自己一句:这一行,每秒会创建多少个对象?它们什么时候会被回收?如果答得不清楚,大概率就是下一个 OOM 的雷。

这次事件还让团队认识到一件事:Go 的"看起来简单"是有代价的。channel + goroutine + select 这套模型表面上是最容易的并发模型,但每一个 API 背后都有 runtime 数据结构生命周期的含义。pprof 是最好的老师——养成"任何长跑服务必须挂 pprof endpoint"的习惯,heap profile 周期采样配上趋势对比,大多数同类 bug 在第一周就会暴露,而不是在第 18 个小时被 K8s OOMKill。这次 18 小时的"准时炸弹"如果按周采样 heap 趋势,首次发布灰度阶段就该被拦下,不会等到生产环境用一次又一次 OOM 来告诉你"你的代码里有数学问题"。

—— 别看了 · 2026