CGO_ENABLED=0不能彻底解决交叉编译问题，仅适用于完全不依赖C库的项目；启用CGO时需严格匹配目标平台工具链、头文件及库路径，否则易导致静默失败。
CGO_ENABLED=0 不能解决所有交叉编译问题
设成 CGO_ENABLED=0 确实能绕过 CGO，但代价是：所有依赖 C 库的 Go 包（比如 net、os/user、os/signal）会退化为纯 Go 实现，可能丢失功能或行为不一致。例如 net 包在禁用 CGO 时用纯 Go DNS 解析，不读取 /etc/resolv.conf，也不支持 systemd-resolved。
- 仅当项目完全不调用 C 函数、且不依赖
net等隐式 CGO 包时，CGO_ENABLED=0才安全 -
go build -ldflags="-s -w"无法弥补 CGO 缺失导致的运行时行为差异 - 交叉编译 Windows 二进制到 Linux 时，即使关 CGO，
syscall层仍可能因平台差异 panic
必须用 CGO 时，交叉编译要配齐目标平台的 C 工具链
启用 CGO_ENABLED=1 后，Go 不会自己带 gcc，而是调用环境变量指定的 CC。没配对，就会报错：exec: "x86_64-w64-mingw32-gcc": executable file not found in $PATH。
- Linux → Windows：装
gcc-mingw-w64，设CC_x86_64_w64_mingw32="x86_64-w64-mingw32-gcc" - macOS → Linux：用
docker run --rm -v $(pwd):/work -w /work golang:1.22-alpine进容器编译，避免本地 macOS 的clang混淆 - ARM64 Linux（如树莓派）：需
aarch64-linux-gnu-gcc，Ubuntu 上装gcc-aarch64-linux-gnu，再设CC_aarch64_linux_gnu="aarch64-linux-gnu-gcc"
CGO 调用的 C 头文件和库路径容易漏配
即使工具链存在，#include <openssl/ssl.h> 这类路径不对，照样编译失败。Go 不自动继承系统 pkg-config 或 CPPFLAGS，全靠显式传参。
- 用
CGO_CFLAGS加头文件路径：CGO_CFLAGS="-I/usr/aarch64-linux-gnu/include" - 用
CGO_LDFLAGS加库路径和链接选项：CGO_LDFLAGS="-L/usr/aarch64-linux-gnu/lib -lssl -lcrypto" - 如果 C 库是静态的（如
libz.a），加-static到CGO_LDFLAGS，否则动态链接时目标机器缺 so 会运行失败 - 交叉编译时别用
pkg-config默认输出——它返回的是宿主机路径，要用PKG_CONFIG_PATH指向目标平台的.pc文件目录
GOOS/GOARCH 和 CC 前缀必须严格匹配
Go 根据 GOOS 和 GOARCH 推导默认 CC 变量名，但推导规则有限。比如 GOOS=linux GOARCH=arm64 对应 CC_arm64_linux，不是 CC_aarch64_linux_gnu —— 中间差了 vendor 和 abi 后缀。
立即学习“go语言免费学习笔记（深入）”；
- 最稳的方式是直接设完整变量：
CC_arm64_linux_gnu="aarch64-linux-gnu-gcc"，然后GOOS=linux GOARCH=arm64 CGO_ENABLED=1 go build - 检查是否生效：加
-x参数看构建日志，确认出现类似exec aarch64-linux-gnu-gcc的调用行 - Mac 上交叉编译 Linux 二进制时，
CC必须指向 Linux 工具链，不能是clang或gcc（即使已安装），否则生成的二进制仍含 macOS syscall
/usr/include，都会让程序在目标机器上静默失败。 
