Go 1.28 提案 #81450：只调预编译 C 库时，cgo 不再需要 C 工具链
Go 1.28 候选特性清单里出现过一条：cgo without a C toolchain。
9 月 10 日，Go 核心开发者 Matloob 在 golang/go 仓库提交了对应提案：proposal: cmd/cgo: cgo without a C toolchain（#81450）。目前提案仍在讨论阶段，没有 PR，也还没被纳入 Go 1.28 里程碑。它指向的方向，是 Go 与 C/C++ 交互方式的一次重构。
几个结论先摆在这里：核心思想合理，技术可行性高，工程实现难度中高；对 Go 编译器侵入性较低，但会明显增加 cmd/cgo 的复杂度；对 C ABI 依赖非常高；对普通 cgo 用户基本透明，对跨平台编译和预编译 .so/.a 特别有价值；对包含 C 源码的 cgo 基本无效，也不能彻底消灭 C 工具链。
关键区分：它不是让 Go「不用 C 了」，而是让 Go 在「只调用已经编译好的 C」时，不再需要再次编译 C。
现在的 cgo，为什么必须要有 C 编译器
假设有这样一段代码：
package main
/*
#include
double cos(double);
*/
import "C"
func main() {
x := C.cos(1.0)
_ = x
}
直觉上流程应该是 Go → C.cos() → libm.so，libm.so 早就编译好了，链接一下就行。
但 cgo 并不是这么工作的。真实链路大致是：
Go source
│
▼
cmd/cgo
│
├─────────┬─────────┐
▼ ▼
C preamble Go wrapper
│ │
▼ │
C compiler │
│ │
▼ ▼
C object ────→ C ABI glue
│
▼
linker
│
▼
libxxx.so
也就是说，当前 cgo 至少在两个环节强依赖 C 工具链：
- 理解 C preamble——解析
/* ... */里的头文件和声明； - 编译 cgo 生成的 C 胶水代码——cgo 会生成一部分 C 代码，需要用 C 编译器编出目标文件。
提案原文也明确指出：即使一个 Go 包不包含任何 C 函数定义，只是通过 C 声明调用一个已经编译好的 .so/.a，构建过程依然需要一套 C 工具链。根源就在 cgo 命令会处理 C preamble 并生成部分 C 代码的胶水层，而这部分代码需要用 C 编译器编译。
把「理解 C」和「编译 C」拆开
现在的 cgo 把「C 声明」「C ABI」「Go C 胶水代码」和「C 编译器」四件事糅在一起，一个环节出问题，整条链路都跑不通。
提案希望拆成两个独立阶段：
开发阶段（包作者，可选借助 C 工具链）：
C header
↓
C compiler（可选）
↓
DWARF / layout information
↓
cgo -gen-binding
↓
binding.go
构建阶段（终端用户，无需 C 工具链）：
binding.go
↓
cgo
↓
Go + assembly trampoline
↓
Go compiler
↓
binary
↓
existing .so / .a
把 C 编译从「每次构建的运行时依赖」，变成「生成 binding 时的可选开发依赖」。
Binding 文件：用 Go 语法重新描述 C API
提案提出的核心新概念叫 binding 文件：用 Go 语法把一段 C 接口重新描述一遍。
提案原文给出的例子，原始 C 声明是：
struct point {
float x;
float y;
};
point global;
float compute(point p0);
对应的手写 binding 文件可能长这样：
//go:build darwin
package mypkg
import "C"
// type definition
//cgo:binding C.point
type Point struct {
x, y float32
}
// global variable
//cgo:binding C.global
var Global Point
// function declaration
//cgo:binding C.compute
func Compute(p0 Point) float32
//cgo:binding 注解的作用，是把一个普通的 Go 类型/变量/函数声明显式绑定到某个 C 符号上。这样 Go 工具链不再需要解析原始 C 头文件，只需要相信这份 binding 描述。
提案原文特别说明，他们不希望把一套完整的 C 预处理器和 C 语法解析器塞进 Go 工具链，因为 C 声明可以涉及嵌套头文件引用、#define 宏、#if/#ifdef 条件编译、平台相关的类型定义等，复杂度极高、维护成本极大。用 Go 语法描述 binding，既保留可读性和可编辑性，也方便复用 Go 工具链现成的文件解析能力。
Binding 怎么生成：cgo -gen-binding
对于已经有 C 工具链的包作者，提案给出了一条自动化路径：
go tool cgo -gen-binding
此时 cgo 会像传统 cgo 一样调用 C 编译器编译 C preamble，但不再生成 C 胶水代码，而是从 DWARF 调试信息里提取类型布局和符号信息，直接生成一份 Go 语法的 binding 文件。以前面 struct point 为例，自动生成的 binding 文件大致是：
//go:build darwin
package mypkg
import "C"
// type definition
//cgo:binding C.struct_point
type _point struct {
x, y float32
}
// global variable
//cgo:binding C_global
var _global _point
// function declaration
//cgo:binding C.compute
func _compute(p0 _point) float32
生成的符号名带下划线前缀，避免和用户自己命名的 binding 冲突。
这份文件生成之后，可以和源码一起 check in 到仓库。一个 cgo 包未来的目录结构可能会变成：
foo/
├── foo.go
├── foo.h
├── binding_linux_amd64.go
├── binding_linux_arm64.go
├── binding_darwin_arm64.go
└── libfoo.so
之后使用这个包的终端用户只需要 go build，不再需要本机装 gcc、clang、头文件、sysroot 这一整套东西。
为什么这能缓解跨平台痛点
C 的条件编译在跨平台场景里向来是老大难，比如：
#if defined(__x86_64__)
...
#elif defined(__aarch64__)
...
#endif
在新模型下，这种平台分支被前移到 binding 生成阶段，而不是留给最终用户的构建阶段：
bindings/
├── amd64/
│ └── binding.go
├── arm64/
│ └── binding.go
└── ...
配合 Go 原生的 //go:build linux && amd64 构建约束，工具链会自动选中对应平台的 binding 文件。C 世界里那些复杂的预处理逻辑，被转移到库作者的开发阶段完成，不再出现在最终用户的构建阶段，对交叉编译体验的提升很直接。
这里有个前提：这套机制不能凭空把 x86 的库变成 ARM 的库，目标平台对应架构的预编译库依然要事先准备好。它解决的是「生成 Go↔C 胶水代码不再需要交叉 C 编译器」，不是「C 库本身可以跨架构自动转换」。
硬骨头一：Go ABI 不等于 C ABI
一个 Go 函数：
func Compute(a float64, b float64) float64
并不能直接映射成一条 CALL compute 指令。Go 有自己的调用约定（参数怎么传、返回值怎么传、栈怎么用、GC 怎么配合），C 也有独立的一套 ABI，两者并不兼容。
提案给出的方案是：cmd/cgo 在 go build 时，根据目标平台的 C ABI 计算每个被声明函数的 calling convention，生成对应的 Go + 汇编 trampoline，负责在 Go ABI 和 C ABI 之间做参数与返回值转换，并处理栈切换等运行时细节。这部分胶水代码全部是 Go 和汇编，可以用 Go 工具链本身编译，不再需要 C 编译器插手。
这条路径行得通的一个重要原因：C ABI 远比 C 语言本身简单和稳定。
C 语言层面充斥着宏、#ifdef、内联、编译器扩展等复杂机制，但落到 ABI 层，只剩下整数、浮点数、指针、结构体、数组、返回值约定、寄存器分配、栈对齐这些相对收敛的问题，并且不同平台的 ABI（Linux amd64 的 System V AMD64 ABI、arm64 的 AAPCS64、Windows 的 x64 ABI）通常非常稳定，多年不会大改。
这也是提案里反复强调「C ABI 不经常变化，因此让 Go 工具链去理解它是可维护的」的原因。
硬骨头二：struct 内存布局与复杂类型
简单函数签名比较好处理，结构体开始变得棘手：
struct Foo {
char a;
int b;
double c;
};
它的内存布局涉及字节偏移、对齐填充等细节，Go 侧的等价结构体必须在 ABI 层面严格一致，哪怕字段类型「看起来一样」也不能掉以轻心。再叠加联合体、位域、匿名结构体/联合体、#pragma pack、平台相关的 long 长度等花样，复杂度会迅速上升。
这个提案最容易落地的场景是「函数 + 标量类型 + 指针 + 简单结构体」，最难啃的骨头是完整覆盖整个 C 类型系统的边角情况。
硬骨头三：C 函数指针回调
比如：
typedef int (*callback)(int);
void register_callback(callback cb);
要在 Go 里把一个函数注册成 C 的回调，涉及回调 trampoline、runtime/cgo 的协作、goroutine/线程调度、栈切换，以及和 GC 的交互，比单向的「Go 调 C」复杂得多。不过这不是全新难题——Go 运行时此前处理传统 cgo 回调时，已经解决过其中相当一部分问题。路径技术可行，只是工程量更大。
硬骨头四：runtime/cgo 也要「去 C 化」
这一步是整个提案能否闭环的关键。目前 runtime/cgo 包本身就是用 C 写的，如果这一层不改造，上层 binding 机制做得再完善，最终仍然会绕回需要 C 编译器。
提案明确提出，要把 runtime/cgo 中原本用 C 实现的部分重写为 Go 和汇编。这样从用户程序到最终的 C ABI 调用，中间所有环节都不再依赖 C 编译器：
Go program
│
▼
cgo
│
▼
Go + assembly glue
│
▼
runtime/cgo（改写为 Go + 汇编）
│
▼
C ABI
│
▼
libfoo.so
需要注意的是，一旦 runtime/cgo 不再包含 C 代码，CGO_CFLAGS 里传入的编译选项将对它失效，这可能会影响到依赖 C sanitizer 的一些使用场景。提案本身也把这一点列为待解决的开放问题之一。
和 Go 1.20／1.21 的路线一脉相承
这个提案不是凭空冒出来的新想法，而是 Go 团队延续多年技术路线的自然延伸。
Go 1.20 让「没有 C 编译器时，CGO_ENABLED=0 也能构建纯 Go 程序」成为常态；Go 1.21 更进一步，Go 官方在关于可复现构建的博客文章中明确提到，Go 1.21 完成了把 host C 工具链和 host 动态链接器从 Go 工具链自身的构建过程中彻底移除，这是可复现构建和供应链安全目标的重要一步（参见 go.dev/blog/rebuild）。
#81450 可以放进这样一条演进脉络：
Go 1.20
│ 为纯 Go 用户消除 C 依赖
▼
Go 1.21
│ 从 Go 工具链自身的构建过程中消除 C 依赖
▼
2026 #81450
│ 为特定 cgo 包消除 C 依赖
▼
未来
│
▼
C ABI 成为 Go 工具链的一等公民概念
对 AI／GPU／原生 SDK 生态的价值
这可能是这份提案最值得 Go 开发者关注的现实落点。像 CUDA、ROCm、TensorRT、ONNX Runtime、OpenSSL、SQLite 扩展，以及各类厂商 SDK，Go 侧真正的需求往往不是「我要编译一段 C 代码」，而是「我要调用一个已经编译好的原生库」。
比如调用 C.cudaMalloc(...) 时，CUDA 运行时库本身早就编译好了，真正需要打通的只是「Go 如何按照 C ABI 去调用 libcuda.so」，而不需要在本地重新走一遍 gcc 编译 C 胶水代码的流程。如果提案最终落地，对 Go 在 AI 基础设施、GPU 计算、原生 SDK 集成方向的开发体验会是一次实打实的提升。
它无法取代所有 cgo
理解这份提案时最容易踩的坑，是误以为它能让所有 cgo 场景都摆脱 C 编译器。只要代码里还包含实际的 C 源码，比如：
/*
#include "foo.h"
static int helper(int x) {
return x * 2;
}
*/
import "C"
C 编译器依然是刚需，因为这里有需要被真正编译的 C 源码。新方案实际上是把 cgo 分成两条并行路径：
cgo
│
┌─────┴──────────┐
│ │
binding-based 传统 cgo
（调用预编译库） （含 C 源码）
│ │
▼ ▼
无需 C 编译器 仍需 C 编译器
这个设计相当务实：它没有试图消灭 C 编译器，而是精准解决了「明明只是调用预编译库、却被迫装一整套工具链」这一个具体痛点。
真正的架构变化：C ABI 成为 Go 工具链的一等公民
如果只把这份提案理解成「cgo 不用装 gcc 了」，其实是低估了它。
过去，Go 把处理 C ABI 这件复杂的事情几乎完全「外包」给了 gcc/clang：
C language → C compiler → object → linker
而在新方案里，cmd/cgo 要开始自己理解 C 的调用约定、结构体内存布局、对齐规则、参数传递方式和返回值约定，并生成对应的 ABI trampoline：
Go toolchain
│
├── Go ABI
│
└── C ABI
这意味着 Go 正在从「调用 C 编译器」转向「直接理解 C ABI」，这是架构层面的变化，也是这份提案里分量最重的部分。
可行性路线
第一阶段：简单 C API（如 int foo(int)、double bar(double)、void *alloc(size_t)）——技术上没有明显障碍。
第二阶段：复杂结构体、指针、回调函数——技术路径清晰，但 runtime、ABI、GC 交互的细节工作量不小。
第三阶段：完整覆盖 C 语言的边角特性（宏、__attribute__、位域、匿名联合体、变长参数函数、线程局部存储、setjmp/longjmp、信号处理、sanitizer 等）——不是做不到，而是没有必要为了「无 C 编译器的 cgo」把整个 C 语言重新实现一遍。提案自己也明确选择了「不去解析完整 C 语言」这条更克制的路线。
最大的风险在 binding 生态
真正可能拖慢这份提案落地的，未必是 ABI 处理的技术难度，而是一个更现实的问题：binding 由谁来维护？
像 libssl、libsqlite、libcurl、libcuda、librocksdb、libtorch 这类库，如果每个 Go 包都要为 linux/amd64、linux/arm64、darwin/arm64、windows/amd64 等多个平台分别维护一份 binding，长期维护成本不容小觑。更棘手的是 binding 与实际 C API 版本漂移的问题：如果上游库更新了结构体字段类型而 binding 没有同步更新，很可能不会在编译期报错，而是直接在运行时表现为内存布局错位，进而引发难以定位的段错误甚至静默内存损坏。
提案里也意识到了这个问题，给出的思路是：在系统存在 C 工具链的情况下，让 go test 重新生成一份 binding 并与 checked-in 版本做一致性校验。这几乎是必须要做的保障机制，未来很可能会进一步演变成 CI 流程里的标准一环，比如 go generate 加 diff 检查，或者类似 go test -verify-cgo-bindings 这样的校验命令。
从长期看，这可能会催生一种新的生态形态：
C library
│
▼
官方 binding 生成器
│
▼
Go binding package
│
├── ABI definitions
├── platform definitions
└── version metadata
对 Go 开发者最现实的影响
如果提案最终落地，未来的 Go 原生集成可能会形成三条并存的路径：
- 纯 Go：Go → Go 编译器，现状已经很好，不受影响；
- Binding-based cgo：Go → Go/汇编 trampoline → libfoo.so，未来面向「只调用预编译库」场景的最舒适选择；
- 传统 cgo：Go → C 源码 → C 编译器 → 目标文件，涉及真实 C 源码时依然存在，属于兼容遗留路径。
小结
golang/go#81450 不是一个「为了少装一个 gcc」的小优化，它实际上同时在做三件事：
- 把 C 声明从构建时依赖变成 checked-in 的元数据；
- 把 C 编译器从 cgo 的运行时依赖降级为可选的开发时依赖；
- 把 C ABI 正式纳入 Go 工具链的能力范围。
第三点，才是这份提案里分量最重的部分。
过去的 cgo 是「请 C 编译器帮 Go 调 C」，这份提案想把它变成「Go 自己理解 C ABI，然后直接调用已经编译好的 C」。结合 Go 1.20／1.21 已持续多年消除 Go 工具链对 host C 工具链依赖的路线来看，#81450 是这条演进路径的自然下一步。
目前提案仍处于早期讨论阶段，围绕 binding 文件应该采用注解式还是独立命名空间等设计细节，Go 团队还在公开征求社区反馈。
参考链接：