Go默认静态链接，CGO_ENABLED=0可确保完全静态二进制；启用CGO则动态链接libc，影响跨平台兼容性；-linkshared为实验性功能，不推荐生产使用。
go build 默认就是静态链接，别被“体积大”吓到
Go 编译器默认使用 -linkmode=internal（内置链接器），且只要不触发 CGO，生成的二进制就是完全静态的：所有 Go 运行时、标准库、第三方包代码全打包进一个文件，ldd ./myapp 会显示 not a dynamic executable。这不是“需要配置才静态”，而是 Go 的出厂设定。所谓“体积大”，通常来自未清理的调试符号（-ldflags="-s -w" 可减 30–50%）、误用 //go:embed 嵌入了百 MB 资源，或启用了 CGO_ENABLED=1 后又没意识到它悄悄引入了 libc 依赖。
CGO_ENABLED=0 和 CGO_ENABLED=1 的真实行为差异
CGO_ENABLED=0 强制禁用 cgo，同时强制走纯 Go 实现路径——比如 net 包用纯 Go DNS 解析器，os/user 会 panic（因无法调用 libc getpwuid），database/sql 驱动只能用纯 Go 版（如 github.com/go-sql-driver/mysql），不能用带 cgo 的 sqlite3 或 pgx。而 CGO_ENABLED=1（默认）下，只要代码里有 // #include、调用了 C.xxx，或导入了含 cgo 的包（如 _ "github.com/mattn/go-sqlite3"），链接器就会自动切到 -linkmode=external，并动态链接系统 libc.so.6、libpthread.so.0 等——此时 ldd 就会列出一堆 so 文件。
-
CGO_ENABLED=0是你控制静态性的最有效开关，适用于 distroless/scratch 容器、嵌入式设备、追求绝对可移植的场景 -
CGO_ENABLED=1不等于“动态链接 Go 代码”，它只是让 Go 混合链接 C 库；Go 自身部分仍为静态打包，只是整体二进制变成了“半静态” - Alpine Linux 上
CGO_ENABLED=1构建的二进制在 glibc 系统上会直接 crash，因为 Alpine 用的是 musl libc
-buildmode=shared 和 -linkshared 是实验性功能，生产慎用
这套机制不是为了替代 CGO_ENABLED，而是另一条独立路径：它试图把 Go 标准库（std）编译成 libstd.so，再让应用只链接它。但实际限制极多：
- 必须先运行
go install -buildmode=shared std生成共享库，且该库与 Go 版本、OS、架构强绑定，无法跨环境复用 -
go build -linkshared后的二进制仍需目标机存在匹配的libstd.so，并正确设置LD_LIBRARY_PATH，彻底放弃“拷即运行”优势 - 不支持用户包动态导出，无法像 C 那样拆业务模块为 so；对 CGO 项目行为不可控，官方明确标注为 experimental
- 多服务共用时才有空间收益；单个服务部署反而增加运维负担，Kubernetes/Docker 生态也无配套支持
真正该关心的不是“静态 or 动态”，而是“要不要依赖系统 libc”
绝大多数 Go 项目根本不需要纠结链接模式，只需明确一点：你的程序是否必须调用系统 C 库？
- 如果只用
net/http、encoding/json、fmt等纯 Go 功能 → 设CGO_ENABLED=0，安心享受静态二进制 - 如果用了
os/user、net.DefaultResolver、sqlite3、zstd→ 必须CGO_ENABLED=1，然后接受它带来的 libc 依赖和跨平台限制 - 不要为了“缩小数字”去开
-linkshared：它不减少总磁盘占用，只把问题从一个文件转移到多个文件+环境配置上
最常被忽略的一点是：静态链接 ≠ 绝对安全。若你嵌入了 C 代码（比如通过 cgo 链接 readline 源码），那这部分 C 的行为仍取决于编译时的 libc 版本和构建标志——真正的可控性，藏在你对 C 依赖的管理深度里，不在 Go 的链接开关表面。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
