CGO_LDFLAGS 必须用于链接非系统默认路径的C库，如自编译的.a/.so、pkg-config查得的非标库或需指定-rpath时；它仅作用于C链接阶段，透传给gcc/clang，支持-L/-l/-Wl,-rpath等选项。
CGO_LDFLAGS 什么时候必须用
当你用 cgo 调用 C 库，且该库不是系统默认路径（比如 /usr/lib）下的标准库时，CGO_LDFLAGS 就绕不开。典型场景包括：链接自己编译的 .a 或 .so、用 pkg-config 查到的非标准路径库、或者需要加 -Wl,-rpath 指定运行时查找路径。
常见错误现象：undefined reference to `xxx`（链接期找不到符号），或运行时报 error while loading shared libraries: libxxx.so: cannot open shared object file（加载期找不到动态库）。
-
CGO_LDFLAGS只影响链接阶段，不控制编译（那是CGO_CFLAGS的事） - 它本质是透传给底层
gcc（或clang）的链接器参数，所以支持所有ld支持的选项，比如-L、-l、-Wl,-rpath - 如果同时用
pkg-config，优先用$(shell pkg-config --libs xxx)动态生成，避免硬编码路径
怎么安全地拼接 CGO_LDFLAGS 值
直接在 shell 里写 export CGO_LDFLAGS="-L/path/to/lib -lmylib" 看似简单，但容易出错——空格、路径含空格、多次覆盖都会翻车。Go 构建时会把环境变量原样塞给 C 链接器，没有解析逻辑。
推荐做法是用构建脚本或 Makefile 控制，而不是全局 export：
立即学习“go语言免费学习笔记（深入）”；
- 用
go build时临时传入：CGO_LDFLAGS="-L./vendor/lib -lmylib -Wl,-rpath,\$ORIGIN/../lib" go build（注意\$ORIGIN要转义） - 路径中含空格？必须用引号包裹整个值：
CGO_LDFLAGS="-L'/path/with space/lib' -lmylib"，不能只包路径部分 - 多个
-L路径之间用空格分隔，不要用冒号或分号；顺序重要：链接器从左到右搜索，靠前的路径优先匹配 - 避免在
.bashrc里永久设置CGO_LDFLAGS，不同项目依赖冲突概率高
CGO_LDFLAGS 和 -ldflags 的区别别搞混
-ldflags 是 Go 自己的链接器参数（作用于 Go 运行时和主二进制），而 CGO_LDFLAGS 是给 C 链接器（gcc）用的。两者完全不互通，也不能互相替代。
典型混淆点：
- 想给最终二进制加版本信息？用
go build -ldflags="-X main.version=1.2.3"，不是CGO_LDFLAGS - 想让 Go 二进制运行时能找到你链接的
libmylib.so？得用CGO_LDFLAGS="-Wl,-rpath,\$ORIGIN/../lib"，不是-ldflags - 混合使用时，
CGO_LDFLAGS先生效（C 链接），再走 Go 链接器；中间任何一步失败，构建就中断
交叉编译时 CGO_LDFLAGS 很可能失效
用 GOOS=linux GOARCH=arm64 go build 时，CGO_LDFLAGS 仍会传给宿主机的 gcc，但宿主机的 gcc 默认不认目标平台的库路径和 ABI。结果往往是：本地能链，交叉编译报 cannot find -lxxx。
解决思路不是硬调 CGO_LDFLAGS，而是换工具链：
- 指定交叉编译用的 C 编译器：
CC_arm64=~/x-tools/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc - 对应地，
CGO_LDFLAGS_arm64才会被读取（Go 支持按平台后缀区分环境变量） - 更稳妥的做法是用
cgo的// #cgo LDFLAGS:注释，在.go文件里按需声明，比环境变量更可控 - 纯静态链接？加上
-ldflags '-extldflags "-static"'，但要注意 C 库本身是否支持静态链接
真正麻烦的是 rpath 在交叉编译后无法验证——你得在目标机器上实际跑一遍 ldd ./binary 才知道路径对不对。这点很容易被跳过，直到部署失败才暴露。
