Go 提案 #81450：cgo 调用预编译 C 库时不再需要 C 工具链
- 提案：golang/go#81450 — proposal: cmd/cgo: cgo without a C toolchain
- 原文来源：tonybai.com/2026/09/14/go-cgo-without-c-toolchain
Go 1.28 的候选特性清单里出现过一项 "cgo without a C toolchain"。2026 年 9 月 10 日，Go 核心开发者 Matloob 在 golang/go 仓库提交了对应提案（#81450）。提案目前处于讨论阶段，没有 PR，也没有明确里程碑（暂未被 Go 1.28 里程碑纳入）。
提案要把 cgo 从「编译 C 代码的机制」升级为「描述并调用 C ABI 的机制」：包库作者在开发阶段用 C 工具链生成一份可读、可编辑、可 check in 的 Go 语法 binding 文件；终端用户执行 go build 时，只需要 Go 工具链本身理解目标平台的 C ABI，生成 Go + 汇编胶水代码即可完成调用，全程不再需要 gcc/clang。该路线与 Go 1.20、1.21 持续剥离 host C 工具链依赖一脉相承，但不覆盖包含 C 源码的传统 cgo 场景。
- Go 核心开发者 Matloob 于 2026 年 9 月 10 日提交提案 #81450，目标是让 cgo 在「只调用预编译 C 库」的场景下摆脱 C 工具链依赖；
- 核心思路是把「理解 C 声明」和「生成 Go↔C 胶水代码」拆成两步，中间用一种新的 Go 语法 binding 文件作为桥梁；
- 关键改造点：cgo 需要自己理解各平台的 C calling convention，生成 Go + 汇编 trampoline；
runtime/cgo也要从 C 改写为 Go + 汇编； - 这不是要消灭 cgo，而是分成 binding-based（无需 C 编译器）和 C 源码编译（仍需 C 编译器）两条路径并存；
- 对跨平台交叉编译，以及调用 CUDA／ROCm／TensorRT 等已编译好的 AI-GPU 原生库价值尤其明显；最大的落地风险不在技术，而在 binding 生态由谁维护。
从 Go 1.20 到 #81450
Go 1.20 让「没有 C 编译器时，CGO_ENABLED=0 也能构建纯 Go 程序」成为常态。Go 1.21 更进一步：Go 官方在关于可复现构建的博客文章中明确提到，Go 1.21 完成了把 host C 工具链和 host 动态链接器从 Go 工具链自身的构建过程中彻底移除，这是可复现构建与供应链安全目标的重要一步（参见 go.dev/blog/rebuild）。
演进路线：
- Go 1.20：为纯 Go 用户消除 C 依赖
- Go 1.21：从 Go 工具链自身的构建过程中消除 C 依赖
- 2026 #81450：为特定 cgo 包消除 C 依赖
- 未来：C ABI 成为 Go 工具链的一等公民概念
「Go 自己理解 C ABI」是什么意思
目前 cgo 的工作方式是：你写 import "C" 和一堆 C 声明，cgo 工具生成 C 胶水代码，再交给 gcc/clang 编译。新提案下，如果只是调用已经编译好的 .so／.a，cgo 只需读懂 C 函数签名和调用约定，直接生成 Go + 汇编的 trampoline 去调用，省掉 C 编译器。这要求 Go 工具链自己实现各平台 C calling convention 的细节，runtime/cgo 也要从 C 改写成 Go + 汇编。
讨论状态
提案仍处于早期讨论阶段。围绕 binding 文件应该采用注解式还是独立命名空间等设计细节，Go 团队还在公开征求社区反馈。感兴趣可以直接前往 golang/go#81450 参与讨论。