CGO静态库与动态库混用必然导致链接错误，因链接器无法兼容两种符号解析策略；必须全静态（如-l:lib.a）或全动态，避免隐式冲突。
CGO环境能跑通，但静态库和动态库混用时必然出链接错误——这不是配置问题，是链接器根本无法同时满足两种符号解析策略。
CGO编译失败：先确认这三件事
很多报错看似是库路径或头文件问题，实际卡在底层环境没就位：
-
CGO_ENABLED=1必须显式设置，Go 1.20+ 在交叉编译或 Alpine 镜像中默认为0 - Linux/macOS 下必须装
gcc（不是clang），Windows 下用MinGW-w64；clang对-static-libgcc支持不一致，容易导致undefined reference to __cxa_atexit - 如果用了 C++ 代码（比如 LevelDB、OpenSSL），
#cgo LDFLAGS必须显式带上-lstdc++或-lc++，否则会报operator new未定义
静态库（.a）链接失败：路径和符号都得对上
静态库不是“放对位置就能链”，它要求头文件声明、函数签名、目标架构三者完全匹配：
-
#cgo CFLAGS: -I./number中的路径必须是相对于go build当前工作目录，不是相对于 .go 文件位置；${SRCDIR}只在#cgo LDFLAGS中有效，CFLAGS不识别 -
ar -t libnumber.a查看归档内容，确认里面真有你调用的函数目标文件（如number.o），而不是空壳或 x86_64 编译却在 arm64 上用 - 若静态库由 C++ 编译生成（
g++ -c），链接时需加-lstdc++，且 Go 文件里#include的头文件不能用extern "C"包裹——CGO 自动处理 C ABI，加了反而破坏符号可见性
动态库（.so/.dylib）加载失败：运行时路径比编译时更关键
编译通过 ≠ 运行成功。动态库在 go run 或 go build 后执行时才会加载，此时只认运行时环境变量：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Linux 下必须设
LD_LIBRARY_PATH=/path/to/your/lib，哪怕#cgo LDFLAGS: -L/path/to/your/lib -lnumber写对了也没用 - macOS 上
DYLD_LIBRARY_PATH在 SIP 启用时被忽略，得用install_name_tool -add_rpath /path/to/your/lib your_binary硬编码路径 - 动态库名带版本号（如
libnumber.so.2）时，-lnumber仍可链接，但运行时必须确保libnumber.so.2文件真实存在——软链接libnumber.so → libnumber.so.2不够，得有实体文件
静态 + 动态混用：链接器会静默选一个，然后崩给你看
当你同时写了 -lnumber（找动态）和 -lnumber 指向静态路径，链接器按顺序找，找到第一个就停。结果不可控，且无警告：
- 避免混用：要么全静态（
-l:libnumber.a强制指定文件名），要么全动态（确保libnumber.so在系统标准路径） - 若必须共存，用绝对路径明确指定：
#cgo LDFLAGS: -l:libnumber.a -L/path/to/static -lstdc++ -L/path/to/dynamic -lfoo - 最稳妥的是源码嵌入：把
number.c直接#include "./number/number.c"进 CGO 注释块，彻底绕过链接阶段
真正麻烦的从来不是“怎么写”，而是“哪个环节悄悄改了 ABI”。比如升级 glibc 后静态库里的 memcpy 符号变了，或者 macOS 更新后 libSystem.B.dylib 移除了某个 weak symbol——这些不会在编译时报错，只会在特定机器上 panic。所以，跨环境部署前务必在目标系统上 ldd your_binary（Linux）或 otool -L your_binary（macOS）验证依赖树。
