本文永久链接 – https://tonybai.com/2025/11/20/proposal-improve-goroutine-stack-using-page-faults

大家好，我是Tony Bai。

Go 语言的 goroutine 以其轻量和高效著称，而其背后一个关键的“魔法”便是可动态增长的栈 (Resizable Stacks)。然而，支撑这个魔法的机制——在几乎每个函数入口处插入的“栈检查”指令——也并非毫无代价。

近日，在 golang-nuts 邮件组，一位名叫 Arseny Samoylov 的年轻开发者发起了一场引人深思的讨论，提出了一个颇具“革命性”的提案：我们能否借鉴 Linux 内核管理线程栈的方式，用“缺页中断”(Page Faults) 机制来取代 Go 现有的“栈检查”？

这个旨在挑战 Go 运行时基石的大胆设想，引来了 Go 语言联合创始人 Rob Pike 的亲自下场。本文中，我们就来简单看看这个看似优雅的提案，为何会引来社区的质疑，并最终被 Rob Pike 本人以“实现过于复杂”为由，泼上一盆“冷水”。

现状的“痛点”——无处不在的“栈检查”

在深入新提案之前，我们必须先理解 Go 当前的栈增长机制及其代价。

当前，Go 编译器会在几乎每一个非叶子函数的序言 (prologue) 部分，插入几条特殊的指令。这些指令的作用是在函数开始执行前，检查当前 goroutine 的剩余栈空间是否足够。如果不足，运行时 (runtime.morestack) 就会介入：分配一个更大的新栈，将旧栈的内容复制过去，调整所有指向栈上变量的指针，然后才继续执行函数。

提案者指出的当前机制的两大痛点：

1. CPU 开销：频繁的栈检查本身就是一种 CPU 开销，尤其是在调用链很深或存在大量无法内联的间接调用（如接口方法调用）时。
2. 代码体积膨胀：每个函数都增加了额外的序言指令（提案者估计约 10 条指令），这会增加 L1 指令缓存 (L1i Cache) 的压力，对计算密集型任务的性能产生负面影响。

基于此，提案者估计，消除栈检查可能会为真实的 Go 应用带来 3% – 5% 的性能提升。

“革命”的设想——通过“缺页中断”实现栈增长

Arseny Samoylov 的提案，其灵感源自现代操作系统（如 Linux）管理原生线程栈的方式。

核心思想：

1. 在创建一个 goroutine 时，不再只分配一个很小的物理内存（当前为 2KB），而是为其预留 (reserve) 一大块虚拟地址空间（例如 8MB），但不立即分配物理内存。
2. 在这块虚拟地址空间的末尾，设置一个“警戒页”(Guard Page)，标记为不可访问。
3. 移除编译器插入的所有“栈检查”指令。
4. 当 goroutine 的栈增长，触及到未分配的内存页时，会触发一次缺页中断 (Page Fault)。操作系统内核会捕获这个中断，并“懒惰地”为其分配一页新的物理内存。
5. 当 goroutine 的栈增长到极致，最终触及到那个“警戒页”时，Go 运行时捕获这个特定的信号，此时才执行现有的栈扩容逻辑。

这个设计的精妙之处在于，它将持续的、遍布每个函数的“栈检查”开销，转变成了仅在栈空间真正耗尽时才发生的一次性、代价较高的“异常处理”。

社区的讨论——一场关于性能、复杂性与可行性的权衡

这个看似优雅的方案，立刻引发了社区开发者的辩论。经验丰富的工程师们很快指出了这个方案背后隐藏的巨大挑战：

1. 中断处理的巨大开销：Jason E. Aten 指出，处理一次缺页中断并由信号处理器接管，其过程极其缓慢。它涉及至少 4 次昂贵的上下文切换（用户态 -> 内核态 -> 信号处理器 -> 内核态 -> 用户态）。这个开销，可能远高于 Go 运行时目前高效的内存分配器。
2. 区分“好”与“坏”的中断：Go 运行时如何能精确地区分出，一次缺页中断是因为“栈需要正常增长”，还是因为一个真正的 Bug（如 nil 指针解引用）？这是一个极其棘手的问题。
3. 虚拟地址空间的消耗：虽然 64 位系统的虚拟地址空间极其巨大，但为每一个 goroutine 都预留 8MB，依然是一个不小的负担。10 万个 goroutine 将消耗 800GB 的虚拟地址空间。
4. 最小栈的增加：最小的物理内存分配单位是一个页（通常是 4KB）。这意味着 goroutine 的最小栈大小将从 2KB 翻倍到 4KB，对于那些拥有数百万个小 goroutine 的应用，这可能会导致物理内存消耗翻倍。

Rob Pike 的“劝退”——来自创始人的最终裁决

当讨论进入白热化时，Go 语言的联合创始人 Rob Pike 亲自下场，给出了他的最终点评。他的观点，冷静而深刻，几乎为这场辩论画上了句号。

首先，他认为提案者夸大了“栈检查”的成本：

“我相信你夸大了（栈检查的）成本。它是可测量的，但并没有你说的那么严重。并且，随着函数内联越来越普遍，函数的体积变大，摊销后的实际成本都在降低。”

更重要的是，他指出了这个提案在工程上的历史困境，这正是“劝退”的核心理由：

“此外，在过去，使用内核traps 来实现栈增长一直都问题重重。我曾见过其他系统尝试这样做，但最终都因为无法预见的复杂性而放弃了。我不是说这做不到，但这绝非易事。而且，由于细节依赖于架构和操作系统，要做到可移植性非常困难。”

最后，他给出了一个简洁而有力的结论：

“这事不归我管，但我不会这么做。”
(It’s not up to me, but I wouldn’t do this.)

小结：永不停歇的探索，Go 演进的生命力

这场关于 goroutine 栈的“革命”提案，最终在创始人的“劝退”中似乎逐渐平息。然而，将此视为一次简单的“失败”，或许会错失其更深远的意义。

Rob Pike 的点评，以其数十年的工程经验和对复杂性的深刻洞察，为这个提案的技术路径亮起了警示的红灯。他指出的“无法预见的复杂性”和“难以解决的可移植性”，是任何试图修改语言运行时的工程师都必须敬畏的“冰山”。

然而，无论这位提案者 Arseny Samoylov 最终是选择接受劝告，还是不顾一切地继续探索并拿出概念验证 (PoC)，这场讨论本身，对 Go 社区而言，都是一件弥足珍贵的好事，它完美地体现了 Go 社区的生命力所在。

Go 语言的演进，正是在这种“大胆设想”与“审慎权衡”的持续张力中，稳步前行的。

资料链接：https://groups.google.com/g/golang-nuts/c/q3iZk0phN9E

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

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

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

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

本文永久链接 – https://tonybai.com/2025/11/20/ai-native-dev-workflow

大家好，我是Tony Bai。

最近半年，我发现我的开发日常，正被一种新的“工作流摩擦”所困扰。

我猜，你可能也感同身受。

我们在一块屏幕上沉浸于IDE中的Go代码，在另一块屏幕上，则像一个勤奋的“学生”，不断向AI大模型提问。我们从代码库中精心挑选上下文，复制，切换窗口，粘贴，然后带着AI给出的答案，再复制，切换，粘贴回来。

我们成了AI时代的“上下文搬运工”和“提示词调优师”。

IDE插件的出现，让AI离我们更近了一步，它像一个“副驾驶”，能为我们提供实时的建议。但它依然无法真正地“动手”——它不能为你运行一次测试，不能帮你执行一次git commit，更无法理解你那套复杂的Makefile里到底藏着什么玄机。

我们拥抱了AI，却发现自己陷入了一个新的“效率怪圈”。我们与AI的协作，始终是割裂的、被动的、充满摩擦的。

我一直在思考，这真的是AI时代软件开发的终极形态吗？一定有更好的方式。一定有一种方法，能让AI不再是一个外部的“辅助工具”，而是成为我们开发流程中一个原生的、可指挥的、能动手干活的“核心成员”。

正是为了系统性地解决这个问题，并把我过去大半年时间的思考、踩坑、实践与沉淀分享出来，我与极客时间合作，倾力打造了一门全新的专栏——《AI原生开发工作流实战：重塑新一代软件工程范式》。

为什么要写这个专栏？

因为我相信，软件开发的范式，正在经历一场深刻的革命。

我们正从“人机协作”的1.0时代，迈向“AI原生”的2.0时代。在这场变革中，开发者的核心价值，将不再仅仅是“写出代码”，而是“设计出能让AI写出高质量代码的工作流”。

而承载这场革命的最佳载体，正是以Claude Code为代表的新一代命令行AI智能体（Command-line Coding Agent）。它们让AI的能力，以前所未有的深度，“活”进了我们最熟悉的开发环境——终端里。

但是，拥有强大的工具，和懂得如何驾驭它，是两回事。

下面是一个AI-开发者集成成熟度模型，你看看你处在哪一层？

我看到的太多开发者，依然在用L1、L2的思维模式，去使用一个为L3、L4工作流设计的强大智能体。这就像开着一辆F1赛车去买菜，不仅没发挥出它的全部性能，还觉得它“不好开”。

这个专栏的目标，就是为你提供那本缺失的“F1赛车驾驶手册”。它不是一本简单的工具说明书，而是一套完整的AI原生开发方法论。我将带你一起，从“第一性原理”出发，重新思考和构建我们在AI时代的软件工程实践。

在这个专栏里，我为你设计了怎样的学习路径？

为了让你能系统性地完成这次思维和技能的升维，我将专栏精心设计为四个层层递进的模块，它就像一张清晰的“升级打怪地图”：

• 模块一：概念篇 · 建立AI原生世界观
  在这一模块，我们将首先统一认知。你将深入理解什么是“规范驱动开发（Spec-Driven Development）”，这一AI原生开发的核心引擎。我们还会一起扫描整个命令行AI Agent的生态，并最终明确，我们为什么选择Claude Code作为核心的实战载体，以及如何通过接入国产大模型（如智普AI）来解决国内开发者的成本与可用性问题。

• 模块二：基础篇 · 掌握与AI伙伴协作的通用语言
  我们将从零开始，手把手带你掌握与AI Agent协作的核心交互模型。你将精通上下文的艺术（CLAUDE.md, agents.md, constitution.md），学会如何为AI注入“长期记忆”和项目“宪法”。你还将掌握强大的自定义指令（Slash Commands），开始将你自己的工作流封装为AI可以执行的命令。学完此模块，你将能为任何项目快速定制一套AI‘说明书’，让它秒懂你的代码库。

• 模块三：进阶篇 · 将Agent锻造成你的专属神器
  这是专栏的“硬核”部分。我们将进入AI Agent的“引擎室”，为你揭示其所有高级特性的工作原理和实战技巧。从安全基石（权限、沙箱、快照回滚），到能力扩展矩阵（Hooks, Skills, Sub-agents, MCP），再到自动化接口（Headless模式），你将学会如何将一个通用AI，彻底“魔改”成一个懂你项目、听你指挥的“专属神器”。学完此模块，你将拥有‘魔改’AI Agent的能力，让它从‘通用模型’变成你的‘专属战友’。

• 模块四：实战篇 · 在真实项目中重塑工程实践
  这是整个专栏的“毕业大戏”。我们将把前面所有学到的理论和技巧，全部应用到一个从零到一的Go项目构建中。在通过顶层设计建立好你的AI驾驶舱后，你将亲历一个功能，是如何在AI原生工作流的加持下，被一步步地设计（spec.md）、规划（plan.md, tasks.md）、编码（TDD）、审查、交付（CI/CD），乃至最终维护与重构的。这将是你把知识转化为能力的最佳演练场。

学完这门课，你将获得什么？

• 一套前沿的开发方法论： 真正掌握“AI原生开发”与“规范驱动开发”的核心思想，而不仅仅是工具的零散技巧。
• 一套通用的Coding Agent驾驭技能： 精通上下文注入、自定义工具和技能、自动化编排等核心技巧，无论未来出现什么新的Coding Agent工具，你都能快速上手。
• 一套可落地的工程实践： 获得AI在需求、设计、TDD、CI/CD、重构等软件工程全流程中的最佳实践和Go语言实战代码。
• 一次思维模式的升级： 完成从“AI工具使用者”到“AI工作流指挥家”的角色转变，构筑在AI时代的个人核心竞争力。

写在最后：一份“抛砖引玉”的邀请

在策划这门课时，我始终保持着一种敬畏之心。

Claude Code是2025年2月才正式进入大众视野的，至今也不过大半年的时间。整个命令行Coding Agent领域，都还处在一个高速演进、日新月异的“黎明时代”。我们所有人，包括我在内，都还在“摸着石头过河”。

因此，这个专栏的内容会更偏向于基础和入门，我希望通过最详尽的示例，为你直观地展现AI原生工作流的巨大潜力。我为你呈现的，更多是我个人在当前阶段探索出的一种可行的工作流，它未必是放之四海而皆准的“最优解”，更谈不上是“终极银弹”。

我更希望这个专栏，能成为一个“抛砖引玉”的平台。

我把我这块“砖”抛出来，是希望能引出你——每一位身处一线的优秀开发者——那块更宝贵的“玉”。我非常期待你在课程的评论区，分享你的思考、你的工作流、你的“最佳实践”。

我相信，关于AI原生开发的未来，最终的答案，一定不是由我一个人，也不是由任何一个AI公司定义的。它将由我们所有拥抱变革、勇于实践的开发者，共同书写。

让我们一起，成为定义这个新时代开发范式的第一批人。

现在，这门凝结了我大半年心血的课程 《AI原生开发工作流实战》 已经在极客时间正式上线了！

专栏为图文形式，共22讲。我为你准备了早鸟优惠 ¥59（原价 ¥99），仅限首周。

扫描下方二维码，立即订阅

用一两杯咖啡的钱，投资一次面向未来的思维和技能升级。

如果你想先了解更详细的课程内容，可以点击「这里」查看专栏的详细目录。

期待在课程中，与你相遇，共同精进！

如果本文对你有所帮助，请帮忙点赞、推荐和转发！

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