本文永久链接 – https://tonybai.com/2025/08/16/brand-new-os-impossible

大家好，我是Tony Bai。

对于许多心怀浪漫主义的开发者来说，“从零开始编写一个属于自己的操作系统”，或许是技术生涯中最终极、最性感的梦想。这几乎是现代编程世界的“创世纪”，是掌控计算机每一个比特的至高权力。

然而，最近一位名为 Wildan M 的工程师，在他的一篇博文中，用一次亲身参与 Redox OS 项目的经历，给我们所有人泼了一盆冷水。他的结论简单而又颠覆：

现在，从零开始编写一个全新的、能被广泛采用的操作系统，已几乎是一项不可能完成的任务。

而其真正的难点，并非我们想象中那个神秘而复杂的内核，而在于内核之外，那座看不见的、庞大到令人绝望的“冰山”。

冰山一角：内核，那个“最简单”的部分

故事的主角是 Redox OS，一个雄心勃勃的项目。它旨在用内存安全的 Rust 语言，构建一个现代的、基于微内核架构的、可以替代 Linux 和 BSD 的完整操作系统。

当我们谈论“写一个 OS”时，我们通常指的是编写内核。那么 Redox OS 的内核有多复杂呢？文章给出了惊人的数据：
* 代码量： 约 3 万行 (30k LoC)。
* 启动速度： 大多数情况下，不到 1 秒。

在短短十年间，Redox 团队已经完成了动态链接、Unix 套接字等核心功能。这无疑是令人敬佩的工程壮举。但 Wildan 指出，这仅仅是浮出水面的冰山一角。一个能启动的内核，距离一个“能用”的操作系统，还有着遥远的距离。

冰山之下：生态移植的“五层地狱”

当作者兴致勃勃地想为 Redox OS 贡献力量，尝试将一些现代程序（如 Go, Node.js, Rust 编译器）移植上去时，他才真正撞上了那座隐藏在水面之下的巨大冰山。

一个现代操作系统之所以“能用”，是因为它能运行我们日常使用的所有软件。而将这些软件“搬”到一个全新的操作系统上，需要闯过一重又一重难关。

第一层：系统调用 (Syscall) 的鸿沟

这是最底层的障碍。每个操作系统都有自己的一套与硬件和内核交互的“语言”，即系统调用。Redox OS 的 syscall 与我们熟知的 Linux 完全不同。这意味着，任何需要与内核打交道的程序（几乎是所有程序），都必须重写这部分逻辑，告诉它如何在新世界里“说话”。

第二层：libc 的重担

为了不让每个程序都去痛苦地学习 syscall 这门“方言”，操作系统通常会提供一个标准的“翻译官”——C 标准库 (libc)。它将复杂的 syscall 封装成开发者熟悉的函数（如 printf, open, read）。因此，一个新 OS 的核心任务之一，就是自己实现一个兼容的 libc。Redox 为此用 Rust 实现了一个名为 relibc 的项目，其工程量之浩大可想而知。

第三层：POSIX 的“几乎兼容”陷阱

即便新 OS 像 Redox 一样，努力兼容 POSIX 这个通用标准，噩梦也远未结束。因为无数现有的软件，早已深度依赖于 Linux 特有的、非 POSIX 的功能，比如解析 /proc 文件系统、操作 cgroups 等。结果就是，即使有了 relibc，你依然需要为这些软件挨个打上无数的“补丁”。文章提到，仅 Redox OS 的官方“软件食谱 (Cookbook)”中，就包含了约 70 个这样的补丁。

第四层：编译器的“先有鸡还是先有蛋”

你想在新 OS 上原生编译软件吗？那你首先需要一个能在这个 OS 上运行的编译器，比如 GCC、Rustc 或 Go 编译器。但问题是，移植编译器本身，就是所有软件移植任务中最复杂、最艰巨的一种。它需要处理极其底层的二进制格式、链接方式和系统调用。这形成了一个经典的“鸡生蛋还是蛋生鸡”的困局。

第五层：语言生态的“次元壁”

如果说移植 C 语言程序还只是“困难模式”，那么移植那些拥有自己庞大生态的现代语言程序（如 Rust, Go, Node.js），则是“地狱模式”。这些语言的包管理器（如 Cargo, Go Modules）会从中央仓库下载海量依赖，你很难像修改 C 代码一样，通过一个简单的 .patch 文件来修复所有问题。唯一的办法，往往是去 fork 无数个核心依赖库，然后逐一修改，这几乎是一项不可能完成的任务。

小结：生态，才是那座无法逾越的山

当 Wildan 经历过这一切后，他得出了文章开头的那个结论。

一个操作系统的成功，或许 20% 在于内核的精巧，而 80% 在于其上能否运行用户想要的所有软件。 后者，那个由编译器、标准库、第三方包、应用软件共同构成的庞大生态，才是真正的、几乎无法被复制的“护城河”。

这就像建造一座城市。你可以设计出最宏伟、最先进的市政厅（内核），但如果没有配套的道路、水电、学校、医院、商店（软件生态），这座城市就永远只是一座无法住人的“鬼城”。

这篇文章并非是要劝退所有对底层技术抱有热情的开发者。正如作者所说，如果你想学习，从零开始或加入 Redox 这样的项目，会是一段极其宝贵的经历。但如果你想构建一个被广泛采用的新 OS，你面对的将不仅仅是技术挑战，更是一个需要说服全球成千上万开发者为你“投票”的社会学难题。

这或许就是对那些仍在坚持构建新 OS 的探索者们，我们应该报以最高敬意的原因。因为他们挑战的，不仅仅是代码，更是一整个时代建立起来的软件文明。

资料链接：https://blog.wellosoft.net/writing-a-brand-new-os-is-almost-impossible-by-now

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/08/07/fork-go-module

大家好，我是Tony Bai。

今天，我想和你聊一个几乎每个 Go 开发者都经历过的场景，一种我们圈内人“只可意会，不可言传”的痛苦。我称之为 Go 模块的“分叉之痛” (The Forking Pain)。

故事通常是这样开始的：你在一个项目中，依赖了一个第三方库。某天，你发现这个库里有一个 Bug，不大不小，但确实影响了你的业务。幸运的是，你深入代码后，发现自己完全有能力修复它，可能只需要改动三五行代码。

你的脑海中浮现出一条清晰、理想的路径：

1. 在 GitHub 上 Fork 这个项目。
2. 在你的 Fork 中修改代码，修复 Bug。
3. 在自己的主项目中验证修复效果。
4. 向上游（Upstream）提交一个干净、优雅的 Pull Request。

然而，当你满怀信心地开始第一步时，现实的残酷才刚刚拉开序幕。

为了让你 Fork 的项目能在本地独立编译通过，你必须将 go.mod 文件中的 module 指令，从 module github.com/upstream/foo 改为 module github.com/bigwhite/foo。而这一改动，就像推倒了第一块多米诺骨牌，一场“全局替换”的噩梦正式降临。

你不得不祭出 sed、grep 或是 IDE 的全局搜索替换功能，将代码库中成百上千个对原仓库的内部引用路径，从 import “github.com/upstream/foo/pkg”，一个个地替换成 “github.com/bigwhite/foo/pkg”。

最终，一个原本 3 行代码的优雅修复，变成了一个包含 300 行导入路径变更的、极其嘈杂的 PR。这就是 Go 模块的“分叉之痛”——它将本应是轻松愉快的社区贡献，变成了一场令人身心俱疲的机械劳动。

问题剖析：我们究竟在“痛”什么？

要理解这种痛苦，我们必须触及 Go 模块系统的一个核心设计：导入路径的唯一性和权威性。

在 Go 的世界里，一个包的导入路径，例如 github.com/upstream/foo/pkg，并不仅仅是一个用于定位代码的地址。它更像是这个包的“身份证号”或者“全名”（Canonical Name），是其在整个 Go 生态中唯一的、权威的身份标识。

这个设计在绝大多数情况下是优点，它保证了模块生态的清晰和无歧义。但当我们 Fork 一个模块时，这个优点就立刻变成了痛点。因为我们 Fork 的目的，通常只是临时修复或改进，我们并不想为它创造一个新的“身份”，我们只想让它暂时“扮演”原来的角色。

但 Go 工具链不允许这种“扮演”。一旦你在 go.mod 中声明了一个新的模块路径，你就必须在整个模块内部，将所有对自身的引用，都更新到这个新的身份上，以维持逻辑上的自洽。

这种设计，在 Fork 场景下，给我们带来了三重具体的痛苦：

1. 繁琐且易错的手工劳动：全局替换是一个极其粗暴的操作。在大型项目中，你很难保证每一次替换都精准无误，遗漏或改错的情况时有发生，为本就复杂的调试过程增添了不必要的干扰。

2. 嘈杂的变更集 (Noisy Diff)：一个 PR 最重要的价值，在于清晰地展示其逻辑变更。但大量的导入路径修改，将真正有价值的几行代码，淹没在成百上千行无意义的变更海洋中。这不仅极大地干扰了 Code Reviewer 的视线，也让 git blame 等工具的输出变得难以追溯。

3. 地狱级的上游合并 (Merge Hell)：这是最致命、最令人崩溃的一点。当你修复完 Bug，准备向上游提交 PR 时，你往往需要先将上游 main 分支的最新变更同步到你的 Fork 中。此时，你会发现，上游的每一次代码重构、每一次文件移动，都会与你本地的路径修改产生大量的合并冲突。这些冲突毫无逻辑可言，纯粹是路径不一致造成的机械性问题，但解决它们却需要耗费数小时甚至数天的时间。

这些痛苦，极大地抑制了社区贡献的热情。许多本可以被轻松修复的 Bug，开发者宁愿选择忍受，也不愿踏入这个“分叉地狱”。

现状与主流“解决方法”

面对这种痛苦，社区经过多年的摸索，也形成了几种主流的、但都不完美的“解决方法”：

方法 A: 全局搜索替换 (Brute-force Search & Replace)

这是最直接、最常见的方法。开发者在 Fork 后，硬着头皮完成全局替换。它的优点是“能用”，但缺点也显而易见——上述的三重痛苦，它一个都没能解决。

方法 B: replace 指令（下游解决方案）

这是一种更“聪明”的方法，但它治标不治本。开发者可以在使用方（也就是你的主项目）的 go.mod 文件中，添加一条 replace 指令：

// in my-main-project/go.mod
replace github.com/upstream/foo v1.2.3 => github.com/bigwhite/foo v1.2.4-fix

这条指令告诉你的主项目：“当你需要 github.com/upstream/foo 这个模块时，请去我的 Fork 地址 github.com/bigwhite/foo 下载。”

这确实能解决下游项目的编译和使用问题。但它完全没有解决 Fork 仓库自身的编译和维护问题。你 Fork 下来的那个项目，如果不在全局替换导入路径的情况下，它自己是无法独立编译通过的。你依然活在“合并地狱”的阴影之下。

方法 C: Vendor 代码（重量级方案）

这是一种更古老、更决绝的方案：将第三方库的源代码，直接完整地复制到自己项目的 vendor 目录中。这彻底切断了与上游 Git 仓库的联系，虽然解决了编译问题，但也引入了极其沉重的维护负担。你将很难同步上游未来的功能更新和重要的安全修复。

新提案解读：#74884 能否带来曙光？

正是在这样的背景下，Go 核心贡献者之一的 Josharian，在 Go 官方仓库提出了 Issue #74884: proposal: cmd/go: make it easier to fork modules。这个提案，为终结这场噩梦带来了一线曙光。

提案的核心思想极其简单和优雅：在 fork 后的 go.mod 文件中，允许一个特殊的、不带版本号的 replace 指令。

让我们来看一个具体的例子。假设你 fork 了 github.com/upstream/foo，并在 go.mod 中修改了模块名：

// In your fork: github.com/bigwhite/foo/go.mod
module github.com/bigwhite/foo

此时，你不需要去修改任何 .go 文件。你只需要在 go.mod 中，再增加下面这一行神奇的指令：

replace github.com/upstream/foo => github.com/bigwhite/foo

这条指令的语义是：告诉 Go 工具链：“在编译我这个模块（github.com/bigwhite/foo）时，只要看到任何对 github.com/upstream/foo/… 的导入，就自动把它理解成是对我自己（github.com/bigwhite/foo/…）的导入。”

这个简单的改动，将带来革命性的好处：

1. 代码零修改：你不再需要改动任何一行 .go 文件的代码。所有的内部导入路径都可以保持原样。
2. PR 干净清爽：提交给上游的 PR，将只包含那几行真正有价值的逻辑变更，让 Code Review 变得高效而专注。
3. 告别合并地狱：由于你的代码库中没有任何路径变更，同步上游的最新代码将变得无比顺畅，再也不会有那些毫无意义的合并冲突。

整个 Fork 的过程，将从一场全局替换的噩梦，简化为在 go.mod 文件中进行两条指令的修改。这无疑将极大地解放生产力。

社区的考虑

当然，社区对于这个提案也有一些讨论和顾虑。

有评论者担心，这会让一个包可以被多个不同的名称引用，从而造成混淆。但我非常赞同提案者 Josharian 的回应：“如果这让你痛苦，那就别这么做。”（If it hurts, don’t do it.）我们不应该因为少数人可能滥用一个特性（比如用 replace “mod” => … 这种极易冲突的短名称），就阻止解决一个普遍存在的、让绝大多数开发者受益的痛点。

此外，社区的讨论也引出了一些更有趣的思考：

• rename vs replace：有评论建议引入一个新的 rename 指令。相比 replace（替换），rename（重命名）的语义可能更清晰，它可能意味着“将旧名称彻底重命名为新名称，并禁止在模块内再使用旧名称”，这能更好地解决“多名称”的混淆问题。

• go install 的兼容性：另一个重要的问题是，当前被 Fork 并修改了 go.mod 的项目，往往无法被 go install 直接安装。任何官方的解决方案，都应该将工具链的这种行为一致性考虑在内，确保 go install 也能正确处理这种“别名”模块。

小结

Go 模块的“分叉之痛”，是 Go 社区一个长期存在、真实且普遍的工程难题。它虽然不影响语言的核心功能，却实实在在地增加了社区协作的摩擦，抑制了开源贡献的活力。

提案 #74884，无论最终是以 replace 还是 rename 的形式，又或是后续有其他新的形式被采纳，都为解决这个问题指明了一个清晰、优雅的方向。一个官方支持的、能让 Fork 过程变得轻松愉快的解决方案，将极大地降低社区贡献的门槛，让“随手修复一个 Bug”真正成为现实。

这不仅关乎工具链的改进，更关乎整个 Go 开源生态的繁荣与健康。让我们拭目以待，并期待 Go 工具链团队能听到社区的呼声，终结这场“全局替换”的噩梦。

资料链接：https://github.com/golang/go/issues/74884

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

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

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

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

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

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