因为go编译器不识别c预处理指令，#include等必须放在紧贴import "c"前的特殊注释块中，且中间不能有空行；否则cgo无法解析，导致符号未定义。
为什么 #include 不能直接写在 Go 源文件里
Go 编译器不识别 C 的预处理指令，#include、#define 或 extern "C" 这类内容必须放在特殊的注释块中，由 cgo 解析。这个注释块要紧贴 import "C" 之前，且中间不能有空行。
- 错误写法：
import "C"上方隔了一行空行，cgo 就会忽略上面的注释 - 头文件路径要用相对路径或系统路径；若用自定义路径（如
./lib/mylib.h），需确保CGO_CFLAGS包含-I./lib - 如果头文件里用了 C++ 特性（比如重载函数），得加
extern "C"包裹声明，否则链接时找不到符号
C.CString 和 C.GoString 的内存生命周期怎么管
cgo 不自动管理 C 侧分配的内存，C.CString 返回的指针指向 C 堆内存，Go 无法 GC；反过来，C.GoString 是复制一份字符串内容到 Go 堆，安全但有开销。
- 用
C.CString后必须配对调用C.free，否则内存泄漏——常见漏掉defer C.free(unsafe.Pointer(cstr)) - 不要把
C.CString的返回值长期保存或跨 goroutine 传递，它只在当前 C 函数调用期间有效（除非你显式malloc） -
C.GoString接收的是以\0结尾的*C.char，若传入非空终止指针，会越界读取直到遇到随机\0
链接外部 C 库时 CGO_LDFLAGS 怎么设才不报 undefined reference
undefined reference 错误基本等于链接器没找到符号定义，不是头文件没包含，而是库没连上或顺序错了。
- 静态库（
.a）：用-L/path/to/lib -lmylib，注意-lmylib会去找libmylib.a或libmylib.so - 动态库（
.so）：除CGO_LDFLAGS外，运行时还要确保LD_LIBRARY_PATH包含库路径，否则 panic: “cannot open shared object file” - 链接顺序敏感：依赖关系靠后的库要写在命令行靠前位置，例如
-lA -lB表示 A 依赖 B，则 B 必须在 A 右边；cgo 里按CGO_LDFLAGS中顺序解析
交叉编译时 cgo 默认关闭，怎么安全启用
GOOS/GOARCH 切换后，cgo 会自动禁用（CGO_ENABLED=0），因为默认找不到对应平台的 C 工具链。强行开启却没配对工具链，编译直接失败。
- 启用前先装好目标平台的交叉编译工具链，比如 macOS 编译 Linux 二进制，要装
x86_64-linux-gnu-gcc并设CC_x86_64_unknown_linux_gnu - 通过环境变量显式指定：
CGO_ENABLED=1 CC_x86_64_unknown_linux_gnu=x86_64-linux-gnu-gcc go build -o app -v - 某些嵌入式场景（如 arm64 Android）还需额外传
--sysroot和-isysroot，这些都得塞进CGO_CFLAGS和CGO_LDFLAGS
最麻烦的从来不是语法，而是头文件和库文件在不同环境下的路径漂移、符号可见性控制、以及 C 内存和 Go GC 的边界怎么划清楚——这些地方一动就崩，还很难 debug。
