Go 默认静态链接，生成单一可执行文件；自 1.5 起支持通过 -buildmode=shared 和 -linkshared 启用动态链接，可显著减小主二进制体积，但需配套共享库，总磁盘占用未必降低。
go 默认静态链接，生成单一可执行文件；自 1.5 起支持通过 `-buildmode=shared` 和 `-linkshared` 启用动态链接，可显著减小主二进制体积，但需配套共享库，总磁盘占用未必降低。
Go 的链接模型与其他主流语言（如 C/C++）有本质区别：默认即静态链接。这意味着 go build 生成的二进制文件已内嵌 Go 运行时、标准库及所有依赖的第三方包代码，无需外部 .so 或 .dll 即可独立运行——这也是 Go “零依赖部署”体验的核心保障。
然而，这种便利性以二进制体积为代价。例如一个包含大量依赖（如 golang.org/x/net, github.com/gorilla/mux, database/sql 驱动等）的 Web 服务，静态编译后可能达数十甚至上百 MB。所谓“600 MB vs 10 MB”的对比虽属极端案例（通常源于未清理调试信息、启用了 CGO 或嵌入了大型资源），但确实反映了静态链接的体积膨胀趋势。
如何启用动态链接？
Go 自 1.5 引入实验性共享库支持，需两步完成：
-
构建共享运行时与标准库（一次即可，供多个项目复用）：
go install -buildmode=shared std runtime
此命令生成 libgo.so（Linux/macOS）或 libgo.dll（Windows），并更新 $GOROOT/pkg/ 下的共享对象索引。
-
编译应用时链接共享库：
go build -linkshared -o myapp myapp.go
输出的 myapp 将仅包含自身代码，依赖符号在运行时由 libgo.so 解析，体积通常可压缩至静态版本的 1/5–1/10。
⚠️ 注意事项：
- 动态链接需目标系统预装匹配版本的 libgo.so，丧失“拷即运行”优势；
- CGO_ENABLED=1 时行为复杂（C 部分仍静态链接，Go 部分动态），不建议混用；
- 生产环境极少采用，因部署一致性、版本兼容性及调试难度显著增加；
- 共享库模式主要适用于内部多服务共用基础组件的场景，通过统一升级 libgo.so 实现热修复。
体积差异的本质
静态链接的“大体积”是把所有依赖打包进单个文件；动态链接只是将公共部分外置为共享库——主二进制变小了，但总磁盘占用 = 主程序 + 共享库 ≈ 原静态二进制大小。真正节省的是内存：多个动态链接进程可共享同一份 libgo.so 的内存页。
推荐实践
- 默认坚持静态链接：利用 Go 的部署简洁性，配合 UPX 压缩（upx --best myapp）可进一步减小体积（注意校验和与反调试影响）；
- 仅当存在明确共享需求时启用动态链接，并建立严格的共享库版本管理流程；
- 若追求极致精简，可尝试 go build -ldflags="-s -w"（剥离符号表与调试信息），常可减少 30%+ 体积。
总之，Go 提供了对链接方式的显式控制权，但选择应基于工程实际——静态链接是 Go 的哲学共识，动态链接是特定场景下的补充选项，而非通用优化手段。
