Go - Tony Bai

本文永久链接 – 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 年的行业数据、巨头财报和底层物理限制，为我们揭示了一个残酷的真相：我们正面临计算能力的“硬墙”，而高效能编程语言，是撞破这堵墙的唯一工具。

2025 年计算的双重瓶颈——电力与芯片

如果你认为算力增长的瓶颈仅仅是芯片（GPU/TPU）的供应，那你就错了。Sutter 引用了微软、亚马逊和 NVIDIA 财报电话会议的内容，指出 2025 年计算增长的第一大瓶颈是“电力”。

微软 CFO：我们不缺 GPU，我们缺的是把它们放进去的“空间和电力”。
亚马逊 CEO：AWS 过去 12 个月增加了 3.8 吉瓦的电力容量，这相当于他们 2022 年的总容量。
NVIDIA CEO 黄仁勋：1 吉瓦的数据中心就是 1 吉瓦的电力。你的“每瓦性能 (Performance per Watt)”直接决定了你的收入。

在这个背景下，能效 (Energy Efficiency) 不再是一个锦上添花的指标，而是直接关乎成本、收入乃至可行性的生死线。

这解释了为什么 C++ 和 Rust 如此重要：它们是目前仅有的、能够提供极致“每瓦性能”和“每晶体管性能”的主流便携式语言。在电力成为硬通货的今天，低效的软件就是在烧钱。

软件的贪婪与硬件的无奈

Sutter 提出了一个深刻的观点：我们对解决更复杂问题的需求，总是超过我们构建更强计算能力的速度。

2007 年的 iOS 开启了移动计算时代。
2022 年的 ChatGPT 开启了生成式 AI 时代。

每一次硬件性能的飞跃，都会迅速被新兴的、更加“贪婪”的软件需求所吞噬。AI 只是这一长串名单中的最新一员。这意味着，我们永远不会拥有“足够快”的硬件，我们永远需要压榨出硬件的最后一滴性能。

因此，C++ 和 Rust 的开发者数量在过去三年（2022-2025）增长最快，这并非巧合，而是行业对高效能计算需求的直接反映。

C++26 —— 安全与性能的“双重奏”

面对 Rust 在内存安全方面的挑战，C++ 并没有坐以待毙。Sutter 详细介绍了即将发布的 C++26 标准在安全性上的重大突破：

消灭未初始化变量：C++26 将默认消除局部变量未初始化导致的未定义行为 (UB)。这是一个迟到但巨大的进步，直接消灭了一大类常见的安全漏洞。
标准库“加固” (Hardening)：C++26 将引入标准库的“加固模式”，对常用的操作（如 vector 访问）进行边界检查。谷歌和苹果的实践数据表明，这种检查的开销极低（小于 1%），但能预防数以千计的潜在 Bug。
契约 (Contracts)：C++26 将引入契约编程（Preconditions, Postconditions），将功能安全提升到语言层面。

Sutter 甚至提出了一个大胆的设想：未来的 C++29 是否应该暂停新特性的开发，专注于“修补漏洞”和“全面硬化”？ 这显示了 C++ 社区在安全性上的决心。

AI 不会取代程序员，它只是计算器

针对“AI 将取代程序员”的焦虑，Sutter 给出了一个冷静而乐观的比喻：AI 之于编程，就像计算器之于数学，或者搜索引擎之于知识。

它是乘数，不是替代品：AI 能极大地减少死记硬背和样板代码的工作，让程序员专注于解决更难、更新的问题。
需求在增长：即使有了 AI 加持，人类程序员的数量依然在快速增长。Atlassian CEO 指出：“如果软件开发的成本减半，我们不会减少一半的程序员，而是会编写两倍的软件，或者解决更复杂的问题。”
AI 的局限：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 Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

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

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

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

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

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

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

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

本文永久链接 – 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 投毒案为例，这是一场教科书式的“偷天换日”：

投毒：攻击者发布了一个包含恶意后门的版本，打上 v1.3.1 的 git 标签。
缓存：Go Module Proxy（Go 生态的官方镜像）忠实地抓取并缓存了这个恶意版本。
清洗：攻击者随即在 GitHub 上强制推送 (force-push) 了一个同名的 v1.3.1 标签，指向一个干净的提交。

结果是分裂的：

审计者在 GitHub 上看到的是“良民”。
编译器从 Proxy 拉取的是“恶棍”。

这标志着旧范式的崩塌：你审查的代码，并不是你运行的代码。

供应链攻击的进化——隐藏在构建链中的幽灵

Jess 指出，这种攻击并非孤例，而是一种正在蔓延的行业趋势。

XZ 后门：恶意载荷被伪装成测试文件，只有在特定的构建脚本执行时才会被注入。在源码树中，它是静止的、无害的；但在构建过程中，它“活”了过来。
npm EventStream：利用版本号策略，让恶意代码只存在于次要版本中，避开对主要版本的审查。

这些案例共同指向一个结论：安全性不能只靠静态的源码分析，必须向右移动，覆盖到最终的构建产物 (Build Artifact)。

新范式确立——能力审计 (Capability Audit)

既然我们无法逐行审查庞大的依赖树，也无法完全信任源码，那么出路在哪里？

答案是：关注行为边界。这就是“能力审计”的核心思想。

借鉴移动端 App 的权限管理模型，我们不再纠结于依赖包内部怎么实现，而是关注它申请了什么能力。

一个 JSON 解析库，如果申请了 net.Dial (网络访问) 能力，这就是异常。
一个日志库，如果申请了 os.Exec (命令执行) 能力，这就是红色警报。

通过监控依赖包的“能力列表”及其变化，我们可以以极低的成本，通过行为特征识别出潜在的供应链攻击，无论源码如何伪装。

Capslock——Google 的开源防御武器

为了将“能力审计”落地，Google 开源了 Capslock。它是一个针对 Go 语言的静态分析工具，通过解析构建产物，构建完整的函数调用图，从而透视出代码的真实能力。

Capslock 能做什么？

Capslock 的核心价值在于“透视”。它不关心代码的具体逻辑，而是关注代码触及了哪些系统边界。它能识别出以下几类关键能力：

网络访问 (NETWORK)：连接互联网或绑定端口。
文件系统 (FILES)：读写文件。
系统执行 (EXEC)：启动子进程。
底层操作 (UNSAFE, REFLECT, CGO)：使用不安全指针、反射或调用 C 代码。

快速上手：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 并非全知全能。了解它的盲区，对于正确使用它至关重要：

CGO 与汇编盲区：Capslock 无法分析 C 代码或汇编代码。如果一个包使用了 CGO，Capslock 会报告它拥有 CGO 能力，但无法告诉你 C 代码内部具体做了什么。这是静态分析的物理边界。
反射与 Unsafe：通过 reflect 或 unsafe 包进行的动态调用，往往让静态分析难以追踪。Capslock 会诚实地报告这些“不可知”的区域为 REFLECT 或 UNSAFE，提示你需要人工审查。
误报 (False Positives)：静态分析假设所有代码路径都可能被执行。如果一段恶意代码藏在一个永远不会为 true 的 if 分支里，Capslock 依然会报告其能力。但在安全领域，“宁可错杀，不可放过” 是正确的策略。

尽管有这些局限，Capslock 依然是目前 Go 生态中进行大规模、自动化能力审计的最佳工具。它为我们在供应链的汪洋大海中，提供了一个至关重要的“雷达”。

构建零信任的开发流程

从“源码审计”到“能力审计”，代表了我们对供应链安全认知的升级。在 AI 辅助编程日益普及、代码生成速度呈指数级增长的今天，这种基于行为边界的守门人机制，将变得愈发重要。

给团队的落地建议：

锁定 Commit：在 go.mod 中尽量使用伪版本号（pseudo-version）锁定 Commit Hash，因为 Tag 是可变的，但 Hash 是不可伪造的。
CI 集成：不要只在本地运行 Capslock，把它变成 CI 的一部分。通过将 Capslock 加入到你的 CI 流水线（例如 GitHub Actions、gitlab ci等），你可以设定一条红线：任何新增的高危能力（如网络、执行），必须触发人工审查阻断。
保持怀疑：当一个纯计算类的库突然想要访问网络时，哪怕源码看起来再正常，也要坚决说不。

小结

安全不是一个状态，而是一个过程。当攻击者学会了“偷天换日”，防御者就必须学会“火眼金睛”。Capslock 和能力审计范式，正是 Go 生态在这个新时代交出的答卷。

参考资料

The Code You Reviewed is Not the Code You Built by Jess McClintock – https://www.youtube.com/watch?v=70ka67DpLPc
capslock repo – https://github.com/google/capslock
Go Supply Chain Attack: Malicious Package Exploits Go Module Proxy Caching for Persistence – https://socket.dev/blog/malicious-package-exploits-go-module-proxy-caching-for-persistence

聊聊你的安全焦虑

供应链攻击防不胜防，Capslock 给了我们一个新的视角。在你日常的开发中，是如何管理第三方依赖安全的？是否遇到过类似的“李鬼”包？或者，你对“能力审计”这种新范式有什么看法？

欢迎在评论区分享你的经验或担忧！ 让我们一起筑牢 Go 生态的安全防线。

如果这篇文章让你对供应链安全有了新的认识，别忘了点个【赞】和【在看】，并转发给你的团队，安全无小事！

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