CGO_ENABLED=0 时 #include 直接报错，不是头文件没找到，是 CGO 根本没启用
Go 编译器默认禁用 CGO，import "C" 前的 #include 行会被忽略或报语法错误。这不是路径问题，是编译器压根不处理 C 预处理器指令。
- 必须显式开启：
CGO_ENABLED=1 go build（Linux/macOS）或set CGO_ENABLED=1 && go build（Windows） -
go env -w CGO_ENABLED=1可设为全局，但注意交叉编译时可能出问题——比如目标平台没有对应 C 工具链 - 检查是否生效：
go env CGO_ENABLED输出应为1
CFLAGS 和 CGO_CFLAGS 到底该用哪个？
CFLAGS 是传统 Makefile 用的环境变量，Go 的 cgo 完全不认；必须用 CGO_CFLAGS（或 CGO_CPPFLAGS、CGO_LDFLAGS）才能透传给底层 C 编译器。
- 加头文件搜索路径：
CGO_CFLAGS="-I/usr/local/include/mylib -I./cdeps" - 定义宏：
CGO_CFLAGS="-DUSE_OPENSSL_V3 -D_GNU_SOURCE" - 警告和标准：
CGO_CFLAGS="-std=c99 -Wall"，但别加-O2——优化由 Go 构建系统统一控制 - 错误示范：
CFLAGS="-I..." go build→ 无效，cgo不读这个
头文件里用了 __attribute__ 或 GNU 扩展，编译失败怎么办？
Go 默认调用系统 C 编译器（通常是 gcc 或 clang），但它的语言标准和扩展支持取决于实际工具链版本和目标平台。某些嵌入式或旧系统头文件依赖 GNU 特性，而 macOS 的 clang 默认不启用 GNU 扩展。
- 强制启用 GNU C 模式：
CGO_CFLAGS="-std=gnu99"或"-std=gnu11" - 如果头文件用了
__attribute__((packed))但报错，试试加-fms-extensions（兼容 MSVC 风格属性）或-fplan9-extensions（Plan 9 风格，少数 BSD 头文件需要） - 避免在
import "C"块里直接写带扩展的声明；优先用包装头文件做适配，比如mylib_wrapper.h中用条件编译屏蔽不兼容部分
ld: library not found for -lxxx 或 undefined reference to 'xxx'
链接阶段失败，说明头文件（.h）找到了，但对应的库文件（.a/.so/.dylib）没被链接，或符号未导出。常见于动态库路径、符号可见性、ABI 不匹配。
立即学习“go语言免费学习笔记（深入）”；
- 确认库存在：
find /usr -name "libxxx.*" 2>/dev/null（Linux/macOS） - 告诉链接器路径：
CGO_LDFLAGS="-L/usr/local/lib -lxxx"；注意-L必须在-l前面，顺序敏感 - macOS 上 dylib 需要额外指定运行时路径：
CGO_LDFLAGS="-L/usr/local/lib -lxxx -Wl,-rpath,/usr/local/lib" - 静态链接失败？检查库是否真为静态：
file /usr/local/lib/libxxx.a；若只有 .so，加-static会失败
#include 了另一个系统头，而那个头在目标环境版本太低、缺定义、或用了你没意识到的编译器扩展。动手前先 gcc -E 展开看看实际预处理结果，比猜快得多。 
