go mod tidy 不解决 cgo 动态链接问题，因其只管理 go 模块依赖，不处理 libc、libpq.so 等系统级共享库；链接失败需检查 c 工具链、ldflags 路径及目标机运行时库是否存在。
Go 模块本身不管理 CGO 动态链接行为，所谓“旧版 CGO 动态链接”问题，本质是误把构建时环境配置缺失、LDFLAGS 写法错误或工具链不匹配，当成了模块依赖问题。
go mod tidy 不会修复 CGO 链接失败
执行 go mod tidy 只会同步 go.sum、下载 Go 包源码、校验哈希，它对 libc、libpq.so.5 或 libusb-1.0.so 这类系统级共享库完全无感知。这些库不在 Go 模块生态里，也不受 go.mod 约束。
- 你看到的 “undefined reference to `PQconnectdb`” 错误，不是模块没拉下来，而是
gcc在链接阶段找不到-lpq对应的 so 文件 -
go list -m all列不出libpq，因为它压根不是 Go 模块 - 即使
go.mod里写了require github.com/jackc/pgx/v5 v5.4.3，它也不能自动帮你装libpq-dev或设置-L/usr/lib/x86_64-linux-gnu
#cgo LDFLAGS 中 -lxxx 的查找逻辑很朴素
cgo 不走 pkg-config，也不读 /etc/ld.so.conf，它只按固定顺序搜索：
- 先查
-L指定的路径（如-L/usr/local/lib） - 再查系统默认路径：
/usr/lib、/lib（Linux），/usr/lib（macOS），C:\Windows\System32（Windows） - 最后拼出文件名：
libxxx.so（Linux）、libxxx.dylib（macOS）、xxx.dll（Windows）
所以 // #cgo LDFLAGS: -lpq 能成功，前提是目标机器上存在 /usr/lib/x86_64-linux-gnu/libpq.so 或 /usr/lib/libpq.so。否则必须显式加 -L：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
// #cgo LDFLAGS: -L/usr/lib/x86_64-linux-gnu -lpq
交叉编译时动态链接几乎必然失败
在 x86_64 宿主机上执行 GOOS=linux GOARCH=arm64 CGO_ENABLED=1 go build，若未指定目标平台工具链，gcc 会尝试链接宿主机的 glibc，而 ARM64 设备（如树莓派）跑的是 musl 或低版本 glibc —— 符号表和 ABI 不兼容，直接报 undefined reference to `clock_gettime`。
- 正确做法是关 CGO：
CGO_ENABLED=0 go build -o myapp，放弃动态库依赖，换纯 Go 实现 - 非要保留 CGO，就得配齐目标工具链：
CC=aarch64-linux-gnu-gcc+CGO_ENABLED=1+-ldflags '-extldflags "-shared"'，且确保aarch64-linux-gnu-gcc能找到对应平台的libpq.so -
go run永远不支持动态链接，它内部强制走静态构建路径，别在这上面试
验证动态链接是否生效的唯一可靠方式
别信日志里有没有 “linking with external linker”，要看生成的二进制本身：
- 运行
ldd your_binary：如果输出里有libpq.so.5 => /usr/lib/x86_64-linux-gnu/libpq.so.5，才算真正动态链接成功 - 如果显示
not a dynamic executable，说明你实际走的是CGO_ENABLED=0或静态链接 - 如果报
error while loading shared libraries: libpq.so.5: cannot open shared object file，说明运行时没装库，或LD_LIBRARY_PATH没设对
真正的难点从来不在 go.mod 里写什么，而在构建机有没有装对 C 工具链、目标机有没有放对 so 文件、以及 -L 和 -l 的顺序与路径是否精确匹配——这些全在模块系统之外。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
