<p>C.xxx报undefined的根本原因是cgo仅识别import "C"上方紧邻的/ /注释块中的C声明与实现，其他位置代码被忽略；类型不匹配、注释格式错误、头文件与实现不一致等均会导致链接失败。</p>
能调，但必须严格按 cgo 的规则来——不是“写个 import 就能用”，而是声明、实现、链接、内存管理四步缺一不可；漏掉任意一环，轻则 undefined: C.xxx，重则运行时崩溃或内存泄漏。
为什么 C.xxx 总是报 undefined？
根本原因不是函数没写，而是 cgo 根本没看到它的声明或实现。它只认紧贴 import "C" 上方的 /* */ 注释块，其他地方写的 C 代码全被忽略。
-
/* #include "mylib.h" */写成// #include "mylib.h"——//注释完全不生效 - C 块和
import "C"之间插了空行、变量声明或 Go 注释 —— 整块失效 - 头文件里只有
int func();（不带参数类型），而 .c 文件里是int func(int a, int b)—— 类型不匹配，链接失败 - 用了
#include "math.c"把实现塞进注释块 —— GCC 能编，但调试信息乱、无法复用、Go 工具链难识别
字符串传参和返回怎么不出错？
Go 字符串和 C 字符串内存模型完全不同：Go string 是只读结构体，不以 \0 结尾；C char* 是可变指针，依赖 \0 终止。直接传会 panic 或读到乱码。
- 传入 C 函数：必须用
C.CString(s)，返回*C.char，且必须配对C.free(unsafe.Pointer(cstr)) - 忘记
C.free→ 确定内存泄漏，Go GC 完全看不见那块 C 堆内存 - C 函数返回
*C.char：若指向常量（如return "ok";），可用C.GoString(cstr)；若来自malloc或strdup，你得自己C.free - 别把
C.CString结果存进全局 map、结构体字段或 channel ——defer失效，生命周期失控
链接静态库 libxxx.a 为什么总 fallback 到 .so？
cgo 默认按 libxxx.so → libxxx.a 顺序搜索，即使你目录下只有 .a，它也会报 “cannot find -lxxx” 或静默 fallback 到系统动态库（如果存在）。
立即学习“go语言免费学习笔记（深入）”；
- 强制静态链接：用绝对路径代替
-lxxx，例如// #cgo LDFLAGS: /path/to/libxxx.a - macOS 需额外加
-Wl,-force_load,/path/to/libxxx.a，否则未引用的符号会被 strip 掉 - Windows 上对应的是
xxx.lib，不是xxx.a；且路径要用正斜杠或双反斜杠 - 交叉编译时，
libxxx.a必须是目标平台 ABI 编译的（比如darwin/arm64库不能用于linux/amd64）
struct 和数组传参要注意什么？
C struct 在 Go 里是 C.struct_xxx，字段顺序、填充、对齐完全由 C 编译器决定，不是 Go 的规则。跨平台或混用不同编译器时极易出错。
- 不要手写 Go struct 去“模拟” C struct —— 字段偏移可能差几个字节，读写越界
- 一律用
C.struct_xxx，字段名和类型由 cgo 自动生成 - 传数组给 C 函数：必须传指针，如
&cArray[0]；不能直接传cArray（Go 不允许取数组变量地址） - 传 slice：用
unsafe.Slice(&slice[0], len(slice))转成*C.T，长度需额外传参，C 层无 runtime 检查
最易被忽略的点是：cgo 不是语法糖，它是编译期桥接机制 —— 每次 go build 都会触发 C 编译器参与，环境变量（CGO_ENABLED、CC）、头文件路径、库架构必须全部对齐，差一个就卡在 undefined 或 linking failed。
