本文永久链接 – https://tonybai.com/2026/01/22/why-are-we-still-talking-about-containers-in-ai-age

大家好，我是Tony Bai。

“如果你在 2014 年告诉我，十年后我们还在讨论容器，我会觉得你疯了。但现在是 2025 年，我们依然在这里，谈论着同一个话题。”

在去年中旬举行的 ContainerDays Hamburg 2025 上，早已宣布“退休”的云原生传奇人物 Kelsey Hightower 发表了一场发人深省的主题演讲。在这个 AI 狂热席卷全球的时刻，他没有随波逐流地去谈论大模型，而是回过头来，向所有技术人抛出了一个灵魂拷问：

为什么我们总是在追逐下一个热点，却从来没有真正完成过手头的工作？

烂尾工程的诅咒——技术圈的“海啸”循环

Kelsey 首先回顾了他职业生涯中经历的三次技术浪潮：Linux 取代 Unix(AIX、Solaris等)、DevOps 的兴起、以及 Docker/Kubernetes 的容器革命。

他敏锐地指出，技术圈似乎陷入了一个无休止的“海啸循环”：

1. 热点爆发：一个新的技术（如 Docker）出现，VC 资金涌入，所有人都在谈论它。
2. 疯狂追逐：为了抢占市场，大家都只做“足够发布”的工作，追求速度而非完美。
3. 未竟而散：还没等这项技术真正成熟、稳定、标准化，下一个热点（如 AI）就来了。于是，半数工程师跳船去追新热点，留下一地鸡毛。

“我们就像一群踢足球的孩子，看到球滚到哪里，所有人就一窝蜂地冲过去，连守门员都离开了球门。结果是，球门大开，后方空虚。”

这就是为什么 10 年过去了，我们还在谈论容器。因为我们当年并没有真正“完成”它。我们留下了无数的复杂性、不兼容和“企业级发行版”，却忘了初衷。

Apple 的“非性感”工作——这才是未来

在演讲中，Kelsey 分享了他最近的一个惊人发现：Apple 正在 macOS 中原生集成容器运行时。

这不是 Docker Desktop，也不是虚拟机套娃，而是操作系统级别的原生支持。这就是 GitHub 上的一个名为 apple/container 的 Apple 开源项目：

Kelsey 提到 contributors 中有 Docker 元老 Michael Crosby ，Michael Crosby 正在 Apple 做着这件“不性感”但极其重要的事情。

Kelsey 认为，这才是容器技术的终局：

• 标准化：容器运行时将成为像 TCP/IP 协议栈一样的操作系统标配，无论你是 Linux、macOS 还是 Windows。
• 隐形化：你不再需要安装 Docker，不再需要关心运行时。它就在那里，像水和电一样自然。
• 应用商店的重构：未来，App Store 分发的可能就是容器镜像，彻底解决依赖冲突和安全沙箱问题。

这正是那些没有去追逐 AI 热点，而是选择留在“球门”前的人，正在默默完成的伟大工程。

关于 AI——不要做“盲目的复制者”

作为 Google 前员工，Kelsey 对 AI 并不陌生。但他对当前的 LLM 热潮保持着清醒的警惕。

他现场演示了一个有趣的实验：询问一个本地运行的 LLM “FreeBSD Service Jails 需要什么版本？”
* AI 的回答：FreeBSD 13（一本正经的胡说八道）。
* 真相：FreeBSD 15（尚未发布）。

Kelsey 指出，现在的 AI 就像一个热心但糊涂的路人，它不懂装懂，只想取悦你。

他的建议是：

1. 不要迷信生成：不要因为 AI 生成了代码就直接用，就像你不会盲目复制 Stack Overflow 的代码一样。
2. 上下文为王：AI 不是魔法，它只是一个强大的搜索引擎。如果你想得到正确答案，你必须先给它提供正确的上下文（Context）。
3. 先训练自己，再训练模型：在成为“提示词工程师”之前，先成为一名合格的工程师。只有当你自己深刻理解了问题，你才能判断 AI 的回答是天才还是垃圾。

给技术人的最后忠告

演讲的最后，Kelsey 回答了关于开源、职业发展和未来的提问。他的几条忠告，值得每一位技术人铭记：

• 关于职业：“你的职业生涯不应该是一场马拉松，而应该是一场接力赛。当你到达巅峰时，想的应该是如何把接力棒交给下一个人，而不是霸占着位置直到倒下。”
• 关于开源：“不要被商业公司的许可证游戏迷惑。如果代码是公开的，你可以 fork，可以学习。真正的开源精神在于分享和协作，而不在于谁拥有控制权。”
• 关于专注：像那家只做钳子的德国公司（Knipex）一样，专注做好一件事。技术圈不缺追风者，缺的是能够沉下心来，把一项技术打磨到极致、直到它变得“无聊”和“隐形”的工匠。

小结

Kelsey Hightower 的这场演讲，是对当前浮躁技术圈的一剂清醒剂。

他提醒我们，技术的真正价值，不在于它有多新、多热，而在于它是否真正解决了问题，是否被完整地交付了。在所有人都在谈论 AI 的今天，或许我们更应该关注那些被遗忘的“球门”，去完成那些尚未完成的伟大工程。

资料链接：https://www.youtube.com/watch?v=x1t2GPChhX8

你的“烂尾”故事

Kelsey 的“海啸循环”论断让人深思。在你的职业生涯中，是否也经历过这种“还没做完旧技术，就被迫去追新热点”的无奈？你认为在这个 AI 时代，我们该如何保持“工匠精神”？

欢迎在评论区分享你的经历或思考！让我们一起在喧嚣中寻找内心的宁静。

如果这篇文章让你停下来思考了片刻，别忘了点个【赞】和【在看】，并转发给那些还在焦虑中奔跑的同行！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/01/22/a-bug-cause-50000-goroutine-leak

大家好，我是Tony Bai。

内存占用 47GB，响应时间飙升至 32秒，Goroutine 数量达到惊人的 50847 个。

这是一个周六凌晨 3 点，发生在核心 API 服务上的真实噩梦。运维正准备重启服务止损，但 Serge Skoredin 敏锐地意识到：这不是普通的内存泄漏，而是一场已经潜伏了 6 周、呈指数级增长的 Goroutine 泄漏。

导致这场灾难的代码，曾通过了三位资深工程师的 Code Review，看起来“完美无缺”。今天，让我们跟随 Serge 的视角，层层剥开这个隐蔽 Bug 的伪装，学习如何避免同样的悲剧发生在你身上。

看似“无辜”的代码

问题的核心出在一个 WebSocket 通知服务中。让我们看看这段“看起来很合理”的代码：

func (s *NotificationService) Subscribe(userID string, ws *websocket.Conn) {
    // 1. 创建带取消功能的 Context
    ctx, cancel := context.WithCancel(context.Background())

    sub := &subscription{
        userID: userID,
        ws:     ws,
        cancel: cancel, // 保存 cancel 函数以便后续调用
    }
    s.subscribers[userID] = sub

    // 2. 启动消息处理和心跳
    go s.pumpMessages(ctx, sub)
    go s.heartbeat(ctx, sub)
}

这看起来非常标准：使用了 context.WithCancel 来管理生命周期，将 cancel 存入结构体以便连接断开时调用。然而，魔鬼就藏在细节里。

泄漏的“三重奏”

经过排查，Serge 发现了导致泄漏的三个致命错误，它们环环相扣，最终酿成了大祸。

Bug #1：无人调用的 cancel

// 预期：连接断开时调用 s.Unsubscribe -> sub.cancel()
// 现实：WebSocket 断开连接时，根本没有人通知 Service 去执行清理逻辑！

当 WebSocket 连接意外断开（如用户直接关掉浏览器），如果没有显式地监听关闭事件并调用清理函数，s.subscribers 中不仅残留了无效的订阅对象，更重要的是，ctx 永远不会被取消。这意味着所有依赖该 ctx 的 Goroutine 将永生。

Bug #2：永不停歇的 Ticker

func (s *NotificationService) heartbeat(ctx context.Context, sub *subscription) {
    ticker := time.NewTicker(30 * time.Second)
    // 致命错误：缺少 defer ticker.Stop()

    for {
        select {
        case <-ctx.Done():
            return // Goroutine 退出了，但 Ticker 还在！
        case <-ticker.C:
            // ...
        }
    }
}

即便 ctx 被取消，Goroutine 退出了，但 time.NewTicker 创建的计时器是由 Go 运行时全局管理的。如果不显式调用 Stop()，Ticker 将永远存在，持续消耗内存和 CPU 资源。 50,000 个泄漏的 Ticker，足以让 Go 运行时崩溃。

Bug #3：阻塞的 Channel

type subscription struct {
    messages chan Message // 无缓冲 Channel（或者缓冲区满了）
    // ...
}

func (s *NotificationService) pumpMessages(...) {
    // ...
    case msg := <-sub.messages:
        sub.ws.WriteJSON(msg)
}

如果写入端还在不断尝试发送消息（因为不知道连接已断开），而读取端（pumpMessages）因为网络阻塞或已退出而不再读取，那么写入端的 Goroutine 就会被永久阻塞在 channel 发送操作上，形成另一种泄漏。

修复与预防：构建防漏体系

修复后的代码不仅加上了必要的清理逻辑，更引入了一套完整的防御体系。

修复：确保生命周期的闭环

• 监听关闭事件：利用 ws.SetCloseHandler 确保在连接断开时主动调用 Unsubscribe。
• 停止 Ticker：永远使用 defer ticker.Stop()。
• 关闭 Channel：在清理时关闭 sub.messages，解除写入端的阻塞。

注：关闭 channel务必由写入者goroutine进行，如果写入者goroutine阻塞在channel写上，此时由其他goroutine close channel，会导致panic on send on closed channel的问题。

预防：Goleak 与监控

Serge 强烈推荐使用 Uber 开源的 goleak 库进行单元测试。

func TestNoGoroutineLeaks(t *testing.T) {
    defer goleak.VerifyNone(t) // 测试结束时检查是否有泄漏的 Goroutine

    // ... 运行测试逻辑 ...
}

此外，在生产环境中，必须监控 runtime.NumGoroutine()。设置合理的告警阈值（例如：当 Goroutine 数量超过正常峰值的 1.5 倍时告警），能在灾难发生前 6 周就发现端倪，而不是等到凌晨 3 点。

注：Go 1.26已经吸收了uber的goleak项目思想，并原生支持goroutine leak检测！此特性可在编译时通过设置GOEXPERIMENT=goroutineleakprofile开启。

小结：经验教训

这次事故给所有 Go 开发者敲响了警钟：

1. Goroutine 必须有明确的退出策略：每当你写下 go func() 时，必须清楚地知道它将在何时、何种条件下退出。
2. Context 是生命线：正确传播和取消 Context 是管理并发生命周期的核心。
3. 资源必须显式释放：Ticker、Channel、Timer 等资源不会自动被垃圾回收，必须手动关闭。
4. 测试是最后一道防线：不要只测试逻辑正确性，还要测试资源清理的正确性。

Goroutine 泄漏是“沉默的杀手”，它不报错、不崩溃，只是悄悄地吞噬你的系统。保持警惕，定期体检，别让它成为你凌晨 3 点的噩梦。

资料链接：https://skoredin.pro/blog/golang/goroutine-leak-debugging

你的“惊魂时刻”

50000 个 Goroutine 的泄漏听起来很吓人，但它可能就潜伏在我们看似正常的代码里。在你的开发生涯中，是否也遇到过类似的内存泄漏或资源耗尽的“惊魂时刻”？你最后是如何定位并解决的？

欢迎在评论区分享你的排查故事或避坑心得！让我们一起把 Bug 扼杀在摇篮里。

如果这篇文章让你对 Goroutine 的生命周期有了更深的敬畏，别忘了点个【赞】和【在看】，并转发给你的团队，今晚睡个好觉！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。