Go默认静态链接，仅当明确依赖系统共享库（如libpq）且能控制目标环境时才需CGO_ENABLED=1配合-extldflags "-shared"启用动态链接；否则应坚持默认静态模式。
go build 默认是静态链接，想用动态链接得手动干预
Go 编译器默认把所有依赖（包括 libc 的封装）打包进二进制，生成完全静态的可执行文件。这不是“编译选项没开”，而是设计使然——go build 根本不提供 --dynamic 这类开关。真要走动态链接，必须绕过默认行为，且只在特定场景下有意义。
典型触发条件是：你明确依赖某个系统级共享库（比如 libusb、libpq），且该库的 Go 封装（如 github.com/jackc/pgconn）启用了 cgo，而你又希望运行时加载系统已安装的版本，而非打包进二进制。
- 必须启用
cgo：设置CGO_ENABLED=1，否则连调用 C 代码的入口都没有 - 禁用静态链接标志：默认
go build会加-extldflags '-static'，需显式覆盖，例如加-ldflags '-extldflags "-shared"'（注意嵌套引号） - 目标系统必须预装对应 so 文件：比如用
libpq.so.5，就得确保目标机器/usr/lib/x86_64-linux-gnu/libpq.so.5存在且 ABI 兼容 -
go run不支持动态链接：它始终走临时构建+静态链接路径，只能用go build
CGO_ENABLED=0 时根本不存在“动态链接”概念
当你执行 CGO_ENABLED=0 go build，Go 会彻底屏蔽 cgo 支持，所有标准库中涉及系统调用的部分（如 net、os/user）自动切换为纯 Go 实现。此时生成的二进制不含任何外部 so 依赖，ldd 查看结果为 not a dynamic executable —— 它压根不是动态可执行格式。
这种模式适合容器部署、无 libc 环境（如 Alpine + musl）、或追求极致分发简单性。但代价明确：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
net库用纯 Go DNS 解析，不读取/etc/resolv.conf，也不支持getaddrinfo的高级特性（如 SRV 记录） -
os/user无法查 NSS 源（LDAP/SSSD），只能解析/etc/passwd文件 - 某些驱动（如 SQLite 的
mattn/go-sqlite3）直接不可用，因它们强制依赖 cgo
交叉编译时动态链接极易出错
用 GOOS=linux GOARCH=arm64 go build 生成 ARM64 二进制时，若启用了 cgo，默认仍尝试链接宿主机（x86_64）的 libc，必然失败。必须同步指定目标平台工具链：
- 安装对应交叉编译器：比如 Ubuntu 上装
gcc-aarch64-linux-gnu - 指定 C 编译器：
CC_aarch64_linux_gnu=aarch64-linux-gnu-gcc - 传入正确 sysroot：通过
-extldflags '--sysroot=/path/to/arm64/sysroot' - 验证输出：用
aarch64-linux-gnu-readelf -d your_binary | grep NEEDED确认列出的是libpthread.so.0而非libc.musl-x86_64.so.1
漏掉任意一环，go build 可能静默成功，但二进制在目标机器上启动即报 no such file or directory —— 实际是动态链接器找不到 so。
真正需要动态链接的场景其实很窄
多数 Go 项目根本不需要动态链接。静态二进制带来的部署一致性、glibc 版本无关性、容器镜像精简等优势，远大于共享库更新带来的微弱收益。只有当满足全部以下条件时，才值得折腾：
- 你的 Go 代码重度封装某个系统库（如 FFmpeg、OpenSSL），且该库本身频繁安全更新
- 你控制目标环境，能保证 so 版本和路径稳定（比如内部私有云，统一部署
libssl1.1） - 你愿意承担调试复杂度：
strace ./binary看 openat 失败、LD_DEBUG=libs查找路径、objdump -T验证符号绑定
否则，老老实实 CGO_ENABLED=0 或接受默认静态链接，反而省心。动态链接不是“更现代”，只是特定约束下的妥协方案。
