2026-01-04 07:17:15
本文永久链接 – https://tonybai.com/2026/01/04/stick-to-the-core-embrace-variables-2025-review-2026-outlook
大家好，我是Tony Bai。
当时钟拨向 2026 年，我不禁回望刚刚过去的 2025。
在技术史上，这注定会被定义为“分水岭”的一年。如果说之前我们还在观望 AI 能画出什么样的图，生成怎样的代码，那么在 2025 年，我们真切地感受到了它对软件工程核心领地的冲击与重塑——从 Google 三巨头定义“AI Agent 元年”，到 CodeRabbit 报告揭示 AI 代码的质量隐忧，再到 Rob Pike 对那封AI “致谢信”的罕见愤怒。
在这样的洪流中，保持定力并不容易。回顾这一年，我庆幸自己做对了一件事：在变化的浪潮中，依然坚持系统性地输出“不变”的价值。
今天，在这个2026年元旦后开工的第一天，我想和大家聊聊我的 2025，以及我对 2026 的硬核规划。
2025 年，我做了一个重要的决定：重塑公众号的内容形态。
在碎片化阅读盛行的当下，我深感很多技术痛点——如并发调度、网络协议、系统底层——是无法通过单篇千字文章讲透的。于是，我推出了“微专栏”模式：用 3-10 篇的体量，像写书一样去深度拆解一个技术专题。
这是一次冒险，但结果令人欣慰。这一年，我们通过 16 个微专栏，构建了一张从底层原理到 AI 前沿的完整技术拼图：
第一块拼图：攻克 Go 并发的“深水区”
并发是 Go 的灵魂，也是最容易出错的地方。
我们通过 《Go并发调度艺术》，跟随 Dmitry Vyukov 的视角亲历了 GMP 模型的演进；通过 《Go并发心智模型课》，完成了从“共享内存”到“信道通信”的思维转变；更为关键的是，《征服Go并发测试》 让我们终于掌握了驯服 Flaky Test 的新武器。
第二块拼图：夯实系统编程与工程底座
在应用层之下，是冰山般的底层细节。
我们潜入内核，在 《Go系统编程：揭秘进程控制、I/O与IPC》 中手写系统级工具；在 《Go网络编程全解：从Socket到HTTP/3》 中打通了网络协议栈的任督二脉。
同时，我们补齐了工程化的关键短板：通过 《Go Context解惑》 掌握了生命周期管理，通过 《Go模块构建与依赖管理》 走出了依赖地狱，用 《Go密码学101》 和 《用Go解锁位运算之美》 强化了基本功，并用 《Go 测试之道》 建立了交付信心。
第三块拼图：架构设计与交互体验
当 Coding 能力溢出，设计能力便决定了上限。
我们探讨了 《API 设计之道：从设计模式到 Gin 工程化实现》 和 《Go开发者的数据库设计之道》，拒绝面条代码。甚至，我们还玩了一把复古与现代结合的 《重塑终端：Go TUI开发入门课》，让命令行工具也能拥有惊艳的交互。
第四块拼图：Gopher 的 AI 破局
这一年，我们不再旁观，而是下场实战。
从 《AI应用开发第一课》 入门，到掌握 《Gemini CLI：重新定义命令行AI开发》，再到硬核的 《Google ADK 实战：用 Go 构建可靠的 AI Agent》，我们证明了 Go 在 AI 时代的无限可能。
除了微专栏，2025 年也是我“系统化输出”的大年。
在极客时间，《Go语言进阶课》 正式上线，帮助无数 Gopher 完成了从熟练到精通的跨越。
更让我惊喜的是，《AI原生开发工作流实战》 在上架短短一个多月内就获得了 3600+ 订阅。这说明大家已经意识到：AI 不仅仅是工具，更是一种全新的开发范式。
与此同时，《Go语言第一课》纸质书也在这一年正式出版，为这一年的“内容实验”画上了一个厚重的句号。
这一系列的产出证明了：在浮躁的时代，深度、系统化的内容依然有着旺盛的生命力。
翻看我 2025 年的博客列表，你会发现我的关注点始终在“底层原理”与“前沿变革”之间穿梭。
关于 Go，我们不仅向前看，也向后看。
Go 团队在这一年对底层的打磨可谓大刀阔斧。我们见证了 GC 的重大演进，《Go新垃圾回收器登场：Green Tea GC》 详细剖析了它如何通过内存感知降低 CPU 开销，《深入 Go Green Tea GC》 则进一步揭示了其架构演进。在性能压榨上，《解锁CPU终极性能：Go原生SIMD包预览版初探》 让我们看到了 Go 在高性能计算领域的野心，尽管 《连 Rob Pike 都感到“担忧”》 也提醒了我们随之而来的复杂性。
同时，我们也向后进行了“Go 考古”，探究了 《错误处理的“语法糖”之战》，以及 《Slice 的“隐秘角落”》 中扩容策略的演变。我们还深入探讨了 《Go 1.26 新特性前瞻》 中的语法糖 new(expr)，以及 《Go 编译器崩溃背后》 的语言规范修正。
关于软件工程，我们保持清醒。
当业界盲目推崇微服务时，我们通过 《“6 个月，47 个微服务”：一场由“简历驱动”引发的架构灾难》 发出了警示；当所有人都在由 AI 生成代码时，我们解读了 《Bug 激增 1.7 倍！AI 写代码：是速度的蜜糖，还是质量的砒霜？》。我们探讨了 《无聊设计的终极奥义》，也重温了 《Code Review 已死？Kent Beck：当 AI 成为“副驾驶”，我们该如何审查代码？》。
关于 AI，我们从旁观走向入局。
这一年，我不再满足于仅仅介绍 AI 工具，而是开始探索 Go 与 AI 的结合点。从 《Google I/O 2025 Go 语言进展》 看到的 AI 赋能，到 《Cloudflare 2025 年度报告》 中 Go 在自动化 API 领域的统治力，再到 《MCP协议注册中心发布》 带来的基础设施变革，我们看到了 Gopher 在 AI 时代的巨大机会。
如果说 2025 年是 AI 辅助编程进入Agent模式（Copilot、Cursor、Claude Code、Gemini cli等）的普及年，那么 2026 年，将是 自主智能系统（Agentic System） 的爆发年。
在 AI 能以百倍速度生成代码的时代，单纯的 Coding 能力正在不可避免地贬值。但架构设计的能力、技术选型的眼光、以及构建复杂系统的智慧，将变得无价。
基于此，在 2026 年，我将在公众号（付费微专栏）和知识星球（免费畅读）双线并行，重点规划以下三大战役：
这不再是写几个 Prompt 的游戏，而是真正软件工程范式的变革。
当“怎么写”变得容易，“写什么”和“怎么设计”就决定了你的上限。
Go 依然是我们的基本盘，但在 2026 年，我们要换个玩法。
当然，作为系统编程的双子星之一，Rust 依然会在我的技术雷达范围内，作为我们拓宽技术视野的重要补充。
2026 年的画卷已经展开。
这是一个技术人最焦虑的时代，也是最令人兴奋的时代。焦虑在于旧经验的快速折旧，兴奋在于个体生产力的无限放大。
新的一年，我希望通过这些深度微专栏和知识星球的陪伴，帮你建立起抵御技术通胀的护城河。
让我们左手握着 Go 与架构设计的工程底气，右手举起 AI Agent 的效率火把，从“代码工人”进化为“系统构建者”。
祝大家在 2026 年，代码无 Bug，架构有灵魂，人生有增量！
扫码加入我的知识星球，2026 全年微专栏以及存量微专栏免费畅读！
你的 2025 关键词
我的 2025 是“坚守与拥抱”。回顾你的 2025，如果用一个词或一句话来总结，会是什么？对于即将到来的 2026，你最大的技术期待又是什么？
欢迎在评论区留下你的年度关键词，让我们一起记录这段不平凡的时光！
如果这篇文章给了你前行的力量，别忘了点个【赞】和【在看】，并转发给你的朋友，让我们在 2026 顶峰相见！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-03 07:49:14
本文永久链接 – https://tonybai.com/2026/01/03/why-cpp-programmers-keep-growing-fast
大家好，我是Tony Bai。
“软件拿走性能的速度，永远比硬件提供性能的速度要快。”
在 AI 狂热、Python 统治胶水层、硬件算力看似无限增长的今天，C++ 标准委员会主席 Herb Sutter 却抛出了一个反直觉的结论：C++ 和 Rust 正在经历前所未有的高速增长。
这并非幸存者偏差。在他最新的博文《Software taketh away faster than hardware giveth》中，Sutter 结合 2025 年的行业数据、巨头财报和底层物理限制，为我们揭示了一个残酷的真相：我们正面临计算能力的“硬墙”，而高效能编程语言，是撞破这堵墙的唯一工具。
如果你认为算力增长的瓶颈仅仅是芯片（GPU/TPU）的供应，那你就错了。Sutter 引用了微软、亚马逊和 NVIDIA 财报电话会议的内容，指出 2025 年计算增长的第一大瓶颈是“电力”。
在这个背景下，能效 (Energy Efficiency) 不再是一个锦上添花的指标，而是直接关乎成本、收入乃至可行性的生死线。
这解释了为什么 C++ 和 Rust 如此重要：它们是目前仅有的、能够提供极致“每瓦性能”和“每晶体管性能”的主流便携式语言。在电力成为硬通货的今天，低效的软件就是在烧钱。
Sutter 提出了一个深刻的观点：我们对解决更复杂问题的需求，总是超过我们构建更强计算能力的速度。
每一次硬件性能的飞跃，都会迅速被新兴的、更加“贪婪”的软件需求所吞噬。AI 只是这一长串名单中的最新一员。这意味着，我们永远不会拥有“足够快”的硬件，我们永远需要压榨出硬件的最后一滴性能。
因此，C++ 和 Rust 的开发者数量在过去三年（2022-2025）增长最快，这并非巧合，而是行业对高效能计算需求的直接反映。
面对 Rust 在内存安全方面的挑战，C++ 并没有坐以待毙。Sutter 详细介绍了即将发布的 C++26 标准在安全性上的重大突破：
Sutter 甚至提出了一个大胆的设想：未来的 C++29 是否应该暂停新特性的开发，专注于“修补漏洞”和“全面硬化”？ 这显示了 C++ 社区在安全性上的决心。
针对“AI 将取代程序员”的焦虑，Sutter 给出了一个冷静而乐观的比喻：AI 之于编程，就像计算器之于数学，或者搜索引擎之于知识。
Herb Sutter 的这篇文章，是对高性能编程语言的一次强力辩护。在摩尔定律放缓、能源危机逼近、AI 需求爆发的今天，掌握一门能与硬件“对话”、能极致利用资源的语言（无论是 C++ 还是 Rust），不仅没有过时，反而变得比以往任何时候都更加重要。
正如他所说：“软件拿走性能的速度，永远比硬件提供性能的速度要快。” 在这场追逐赛中，高效能开发者将永远是稀缺资源。
资料链接：https://herbsutter.com/2025/12/30/software-taketh-away-faster-than-hardware-giveth-why-c-programmers-keep-growing-fast-despite-competition-safety-and-ai
你的“能效”焦虑
在你的日常开发中，是否也感受到了“算力不够用”或者“云成本过高”的压力？你认为在 AI 时代，掌握一门高性能系统级语言（C++/Rust）是变得更重要了，还是更边缘化了？
欢迎在评论区分享你的看法和职业规划！ 让我们一起探讨如何在算力瓶颈时代突围。
如果这篇文章为你拨开了迷雾，别忘了点个【赞】和【在看】，并转发给身边那些坚持底层开发的“硬核”朋友！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-02 20:08:12
本文永久链接 – https://tonybai.com/2026/01/02/kent-beck-ai-era-code-review-end-and-rebirth
大家好，我是Tony Bai。
“以前是‘嘿，能在合并前帮我看一眼吗？’……现在是‘我在海滩上和一个神灯精灵结对编程’。”
极限编程 (XP) 和测试驱动开发 (TDD) 的奠基人 Kent Beck，最近发表了一篇题为《Party of One for Code Review!》（代码审查的一人派对！）的博客。
这是一个略带伤感，却又无比清醒的时刻。曾经，代码审查是软件工程中最具社交属性的活动之一，是团队知识共享的纽带。但在 AI 能够以百倍于人类的速度生成代码的今天，那个属于人类互相 Review 的黄金时代，似乎正在走向终结。
取而代之的，是一场孤独的、高效的、由人类与 AI 共舞的“一人派对”。在这场派对中，代码审查并未消失，而是迎来了一场深刻的重生。
在过去的几十年里，代码审查建立在一个默认的“社交契约”之上：我们是平等的队友，我们以相似的速度工作，我们有义务互相检查。
然而，生成式 AI 的介入，彻底打破了这个平衡，导致了旧式 Code Review 的终结。
Kent Beck 指出，当 AI 这个“神灯精灵”成为你的结对伙伴时，生产代码不再是瓶颈。你可以还没到午饭时间，就生成并探索了三种不同的实现方案。这种速度是任何人类同事都无法匹配的。
当你的同事还在为自己的任务焦头烂额时，你已经用 AI 生成了海量的代码。要求他们在一个下午读懂你和 AI 交互了数小时产生的逻辑，不仅是不公平的，甚至是不可行的。
于是，我们被迫进入了“一人派对”模式。你是唯一的作者，也是唯一的审查者。 传统的、依赖同步协作的审查模式，在 AI 的洪流面前显得苍白无力。
如果不再依赖同事来找 Bug，代码审查还有存在的必要吗？Kent Beck 认为，它不仅有必要，而且比以往任何时候都重要。
代码审查正在重生，它的关注点从“纠错”转移到了两个更高维度的使命上：
AI 是自信的，它生成的代码往往看起来完美无缺。新时代的审查，首先是一场“图灵测试”般的博弈。
你需要时刻保持警惕：“这看起来是对的，但它真的在做我要求它做的事吗？” Review 的本质，变成了确认 AI 是否忠实执行了人类的意图，而非纠结于语法细节。
这是 Kent Beck 最深刻的洞见。他担忧的不是 Bug，而是代码库的可操作性。
“如果结构变得过于纠缠，耦合变得太紧，精灵（AI）就会开始犯错。”
当大量代码被快速生成时，代码库很容易陷入混乱的熵增，这种现象被称为“结构性漂移”。一旦代码结构腐化，AI 对上下文的理解能力就会断崖式下跌，最终导致开发效率的崩盘。
因此，重生的代码审查，其核心使命是守护架构的健康。我们要确保代码库始终保持在一个“既让人类可读，又让 AI 可理解”的状态。
在“一人派对”中，既然没有了人类队友，我们就需要新的盟友。Kent Beck 提到，他正在尝试使用像 CodeRabbit 这样的 AI 代码审查工具。
但他并不是想找一个“自动通过器”，而是将 AI 视为一个“不知疲倦的检查员”：
这就是新时代的讽刺与美妙：我们正在用 AI 来审查 AI，以确保人类依然掌握着系统的控制权。
文章的字里行间，流露出一种作为“老派黑客”的孤独感。Kent Beck 怀念那些与人激烈讨论、在白板前碰撞思维火花的日子。
“我现在独自工作，生成代码飞快……但这不那么令人满足。”
在 AI 时代，工程师的角色正在发生质变。我们从一群围着篝火（代码）取暖的部落成员，变成了独自驾驶飞船穿梭星际的领航员。AI 是我们强大的副驾驶，但方向盘，始终在且必须在人类手中。
“一人派对”并不意味着彻底的孤独，它意味着更高的责任。
代码审查并没有死，它只是褪去了社交的外衣，重生为一种更纯粹、更严谨的工程纪律。在这场派对中，我们虽然独自起舞，但我们的舞步（代码结构）必须足够清晰、优雅，才能让那位强大的 AI 舞伴，始终跟随我们的节奏，而不至于踩到我们的脚。
资料链接：https://tidyfirst.substack.com/p/party-of-one-for-code-review
你的“派对”体验
Kent Beck 的“一人派对”，或许是每位 AI 时代开发者的必经之路。在你的工作中，是否也体验过这种“生成代码飞快，但无人Review”的孤独与不安？你是如何保证这些 AI 代码的质量和架构健康的？
欢迎在评论区分享你的故事或困惑，让我们在这场孤独的派对中找到彼此。
如果这篇文章触动了你，别忘了点个【赞】和【在看】，并分享给那些同样在 AI 浪潮中思考未来的朋友！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-02 07:43:16
本文永久链接 – https://tonybai.com/2026/01/02/go-supply-chain-attack-source-code-to-capability-auditing-paradigm-shift
大家好，我是Tony Bai。
在软件供应链安全的传统认知中，我们默认遵循一个假设：“代码即真理”。如果你审查了 GitHub 上的源码，确认它是安全的，那么你部署的服务就应该是安全的。
然而，2025 年初在 Go 生态中爆发的 BoltDB 投毒事件，以及之前的 XZ 后门事件，无情地粉碎了这个假设。攻击者正在利用构建系统的复杂性和 Git 标签的可变性，在“源码”与“构建产物”之间制造出一片致命的盲区。
面对这种不对称的战争，传统的“源码审计”已显疲态。在 GopherCon 2025 上，Google Cloud 安全专家 Jess McClintock 提出了一个新观点：我们需要一场防御范式的转移——从关注代码“写了什么”，转向关注构建产物“能做什么”。
本文将带你深入这场范式转移的核心，剖析攻击手段的演变，并手把手教你使用 Google 开源的 Capslock 工具，开启你的“能力审计”之路。
“源码审计”失效的根本原因，在于源码仓库不再是单一的事实来源 (Source of Truth)。
以 BoltDB 投毒案为例，这是一场教科书式的“偷天换日”：
结果是分裂的：
这标志着旧范式的崩塌：你审查的代码，并不是你运行的代码。
Jess 指出，这种攻击并非孤例，而是一种正在蔓延的行业趋势。
这些案例共同指向一个结论：安全性不能只靠静态的源码分析，必须向右移动，覆盖到最终的构建产物 (Build Artifact)。
既然我们无法逐行审查庞大的依赖树，也无法完全信任源码，那么出路在哪里？
答案是：关注行为边界。这就是“能力审计”的核心思想。
借鉴移动端 App 的权限管理模型，我们不再纠结于依赖包内部怎么实现，而是关注它申请了什么能力。
通过监控依赖包的“能力列表”及其变化，我们可以以极低的成本，通过行为特征识别出潜在的供应链攻击，无论源码如何伪装。
为了将“能力审计”落地，Google 开源了 Capslock。它是一个针对 Go 语言的静态分析工具，通过解析构建产物，构建完整的函数调用图，从而透视出代码的真实能力。
Capslock 的核心价值在于“透视”。它不关心代码的具体逻辑，而是关注代码触及了哪些系统边界。它能识别出以下几类关键能力：
想体验“能力审计”的威力？只需三步。
1. 安装工具
确保你安装了最新的 Go 环境，然后运行：
$go install github.com/google/capslock/cmd/capslock@latest
2. 扫描当前项目
在你的 Go 项目根目录下运行，Capslock 会自动分析当前模块及其所有依赖，以我的issue2md开源项目为例：
$capslock -packages=.
Capslock is an experimental tool for static analysis of Go packages.
Share feedback and file bugs at https://github.com/google/capslock.
For additional debugging signals, use verbose mode with -output=verbose
To get machine-readable full analysis output, use -output=json
FILES: 1 references
NETWORK: 1 references
REFLECT: 2 references
我们看到该issue2md项目使用了文件访问、网络访问以及反射能力。如果你要看具体是哪些代码用到了这些能力，可以让capslock输出verbose信息：
$capslock -packages=. -output=v
Capslock is an experimental tool for static analysis of Go packages.
Share feedback and file bugs at https://github.com/google/capslock.
To get machine-readable full analysis output, use -output=json
FILES: 1 references (1 direct, 0 transitive)
Example callpath:
github.com/bigwhite/issue2md.main
main.go:29:11:log.Fatal
log.go:423:12:(*log.Logger).output
log.go:244:23:(*os.File).Write
NETWORK: 1 references (1 direct, 0 transitive)
Example callpath:
github.com/bigwhite/issue2md.main
main.go:24:23:net/http.FileServer
REFLECT: 2 references (1 direct, 1 transitive)
Example callpath:
github.com/bigwhite/issue2md.main
main.go:18:12:flag.Parse
flag.go:1188:19:(*flag.FlagSet).Parse
flag.go:1157:26:(*flag.FlagSet).parseOne
flag.go:1112:11:(*flag.FlagSet).usage
flag.go:1068:17:(*flag.FlagSet).defaultUsage
flag.go:690:17:(*flag.FlagSet).PrintDefaults
flag.go:609:12:(*flag.FlagSet).VisitAll
flag.go:458:5:(*flag.FlagSet).PrintDefaults$1
flag.go:630:32:flag.isZeroValue
flag.go:545:18:reflect.New
3. 进阶：对比版本差异 (Diff)
这是 Capslock 最核心、也最强大的用法之一。当你想升级某个依赖时，如何知道新版本是否引入了恶意行为？下面以我fork的govanityurls为例，看一下如何进行版本能力的差异对比。我的govanityurls的唯一依赖是gopkg.in/yaml.v2。
# 1. 保存依赖的旧版本的分析结果
capslock -packages=gopkg.in/yaml.v2 -output=json > v2.3.0.json
# 2. 比较新版本 (假设你已经 go get了新版本，比如v2.4.0)
$capslock -packages=gopkg.in/yaml.v2 -output=compare ./v2.3.0.json
如果输出显示新增了 NETWORK 或 EXEC 能力，这就是一个必须要人工介入审查的红色警报。在我这个示例中，gopkg.in/yaml.v2 v2.4.0，相对于v2.3.0没有能力增加。
作为一个静态分析工具，Capslock 并非全知全能。了解它的盲区，对于正确使用它至关重要：
尽管有这些局限，Capslock 依然是目前 Go 生态中进行大规模、自动化能力审计的最佳工具。它为我们在供应链的汪洋大海中，提供了一个至关重要的“雷达”。
从“源码审计”到“能力审计”，代表了我们对供应链安全认知的升级。在 AI 辅助编程日益普及、代码生成速度呈指数级增长的今天，这种基于行为边界的守门人机制，将变得愈发重要。
给团队的落地建议：
安全不是一个状态，而是一个过程。当攻击者学会了“偷天换日”，防御者就必须学会“火眼金睛”。Capslock 和能力审计范式，正是 Go 生态在这个新时代交出的答卷。
聊聊你的安全焦虑
供应链攻击防不胜防，Capslock 给了我们一个新的视角。在你日常的开发中，是如何管理第三方依赖安全的？是否遇到过类似的“李鬼”包？或者，你对“能力审计”这种新范式有什么看法？
欢迎在评论区分享你的经验或担忧！ 让我们一起筑牢 Go 生态的安全防线。
如果这篇文章让你对供应链安全有了新的认识，别忘了点个【赞】和【在看】，并转发给你的团队，安全无小事！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-01-01 13:16:40
本文永久链接 – https://tonybai.com/2026/01/01/go-archaeology-porting-policy
大家好，我是Tony Bai。
当我们津津乐道于 Go 语言强大的跨平台编译能力——只需一个 GOOS=linux GOARCH=amd64 就能在 Mac 上编译出 Linux Go程序时，你是否想过，这些操作系统和 CPU 架构的组合（Port）是如何被选入 Go 核心代码库的？
为什么 linux/amd64 稳如泰山，而 darwin/386 却消失在历史长河中？为什么新兴的 linux/riscv64 或 linux/loong64 能被接纳？
这一切的背后，都遵循着一份严谨的 Go Porting Policy。今天，我们就来翻开这份“法典”，一探究竟。
在 Go 的语境下，一个 Port 指的是 操作系统 (OS) 与 处理器架构 (Architecture) 的特定组合。例如：
每一个 Port 的引入，都意味着 Go 编译器后端需要生成对应的机器码，运行时（Runtime）需要处理特定的系统调用、内存管理和线程调度。这是一项巨大的工程。
Go 官方将 Ports 分为两类，这并非歧视，而是基于稳定性承诺和维护成本的考量。
First-Class Ports 是 Go 官方（Google Go Team）承诺全力支持的平台。它们享有最高级别的待遇，也承担着最重的责任：
目前的 First-Class Ports 名单（极少，只有核心的几个）：
* linux/amd64, linux/386, linux/arm, linux/arm64
* darwin/amd64, darwin/arm64 (macOS)
* windows/amd64, windows/386
冷知识：Linux 下只有使用 glibc 的系统才算 First-Class。使用 musl (如 Alpine Linux) 的并不在这个名单里，虽然它们通常也能工作得很好。
除了上述几个“亲儿子”，Go 支持的几十种其他平台（如 freebsd/*, openbsd/*, netbsd/*, aix/*, illumos/*, plan9/*, js/wasm 等）都属于 Secondary Ports。
它们的生存法则完全不同：
这意味着，如果你想让 Go 支持一个冷门的嵌入式系统，你不仅要贡献代码，还得长期确保持续集成（CI）是绿的。
想让 Go 支持一个新的芯片架构（比如龙芯 LoongArch）？流程是严格的：
Go 不会无限制地背负历史包袱。一个 Port 如果满足以下条件，可能会被移除：
这就是为什么 Go 在某个版本后不再支持 Windows XP 或 macOS 10.12 的原因——为了让有限的开发资源聚焦在更广泛使用的系统上。
Go 的 Porting Policy 展示了一个成熟开源项目的治理智慧：核心聚焦，边界开放，权责对等。
它保证了 Go 在主流平台上的坚如磐石，同时也通过社区机制，让 Go 的触角延伸到了无数小众和新兴的领域。下次当你为一个冷门平台编译 Go 程序成功时，别忘了感谢那些默默维护 Builder 的社区志愿者们。
参考资料：https://go.dev/wiki/PortingPolicy
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
