Go默认静态链接，模块依赖与二进制链接解耦；所谓“动态”实为cgo副作用：CGO_ENABLED=1时自动动态链接libc等系统库，CGO_ENABLED=0则强制纯Go实现并保持完全静态。
go build 默认静态链接，所谓“模块依赖动态链接”在 Go 中并不存在——Go 的模块（go.mod）只管源码依赖解析与版本锁定，和二进制链接方式完全解耦。
你看到的“动态”行为，几乎都来自 cgo 的副作用，而不是模块系统本身。下面分几个实际场景讲清楚。
为什么 go.mod 里写的是 v1.2.3，但 ldd 却显示 libc.so.6？
这是最典型的误判点：模块版本和链接方式毫无关系。
-
go.mod中的require github.com/mattn/go-sqlite3 v1.14.17只表示“我要用这个版本的源码”，它不决定编译时是否链接libsqlite3.so - 真正触发动态链接的是该包内部用了
// #include <sqlite3.h>+C.sqlite3_open调用，且CGO_ENABLED=1（默认值） - 一旦启用 cgo，Go 编译器自动切换为动态链接模式，把
libc、libpthread等系统库作为运行时依赖
换句话说：模块管理负责“代码从哪来”，cgo 和构建环境才决定“二进制怎么连”。
CGO_ENABLED=0 时，模块还能正常 resolve 吗？
能，而且更干净。
立即学习“go语言免费学习笔记（深入）”；
-
CGO_ENABLED=0仅禁用 cgo 支持，不影响go mod的任何功能：下载、校验、replace、exclude全部照常工作 - 但所有依赖中含 cgo 的包（如
go-sqlite3、go-sql-driver/mysql、net包在某些平台调用 getaddrinfo）会直接报错：import "C" not allowed - 此时若需数据库能力，必须换纯 Go 实现的驱动（如
github.com/ziutek/mymysql或sqlc生成的无 cgo 模式）
注意：CGO_ENABLED=0 不会删掉 go.mod 里的 require 行，只是让构建阶段跳过那些无法编译的包。
如何判断某个模块是否暗藏动态链接风险？
看它是否在源码里出现以下任一特征：
- 文件顶部有
import "C"（哪怕没实际调用 C 函数） - 存在
// #include、// #cgo、// #define等注释 - 调用了
C.xxx形式的函数（如C.malloc、C.getenv） - 依赖链中任意一环满足以上条件（例如你只 import
github.com/gin-gonic/gin，但它依赖golang.org/x/sys/unix，而后者在 Linux 上用 cgo 实现 syscall）
快速验证命令：go list -f '{{.CgoFiles}}' github.com/some/pkg，输出非空切片即含 cgo。
真正容易被忽略的，是那些“看起来纯 Go、实则底层偷偷用 cgo”的标准库子包，比如 net、os/user、os/signal 在不同平台行为不一致——它们不会在你的 go.mod 里显式出现，却能让一个原本静态的二进制突然变成动态依赖。
