C.some_func报undefined的根本原因是cgo仅解析import "C"上方紧贴注释块中的C代码，不自动扫描.c文件或头文件路径；必须显式包含头文件、提供完整函数签名、处理extern "C"及依赖的系统头文件。
C.some_func报undefined，到底该往哪写声明
根本不是函数没实现，而是 Go 编译器压根没“看见”它。cgo 不扫描 .c 文件，也不自动解析头文件路径，只认 import "C" 上方紧贴的注释块里、C 编译器能当场解析的原型。
-
/* #include "mylib.h" */必须存在，且mylib.h和 .go 文件在同一目录；若在./c/include/下，得写/* #include "../c/include/mylib.h" */或加// #cgo CFLAGS: -I./c/include - 头文件里不能只写
int some_func();，必须是完整签名，比如int some_func(const char*, size_t); - 如果
mylib.h依赖stdlib.h或string.h，得显式写进注释块：/* #include <stdlib.h> #include <string.h> #include "mylib.h" */</string.h></stdlib.h> - C++ 实现的库，头文件中函数声明必须包在
extern "C"块里，否则名字被 mangling，C.some_func就彻底消失
字符串传给 C 函数，为什么一跑就 panic
Go 的 string 不以 \0 结尾，底层内存不可变、不归 C 管；直接传 string 或用 C.CString 后不配对 C.free，大概率越界或释放后读。
- 输入字符串：优先用
C.CBytes([]byte(s))→ 返回unsafe.Pointer，再转(*C.char)，并显式传长度；它不扫描\0，也避免空字符截断 -
C.CString(s)后必须立刻C.free(unsafe.Pointer(cstr))；循环里别写defer，因为 defer 绑定的是变量值，不是每次调用的地址，会导致只释放最后一次分配的内存 - 输出字符串：C 函数返回
char*时，用C.GoStringN(cstr, n)（n 是 C 侧明确返回的字节数），别用C.GoString(cstr)——后者会调strlen，遇到中间\0就截断 - 绝对不要把
C.CString结果存进map、全局变量或 channel；defer 失效，内存永远不释放
链接 libxxx.a 总说找不到符号，是不是路径写错了
cgo 默认只找动态库（.so/.dylib），同目录放了 libxxx.a 也不会用——除非你明说“我要静态链接”，而且路径、命名、架构全对。
-
// #cgo LDFLAGS: -L./libs -lxxx中的-lxxx对应的是libxxx.a（Linux/macOS）或xxx.lib（Windows），不是xxx.a - 强制静态链接：Linux 加
-static-xxx，macOS 加-Wl,-force_load,./libs/libxxx.a（否则未引用的符号会被 strip） - 交叉编译时（如
darwin/arm64→linux/amd64），libxxx.a必须是目标平台 ABI 编译的，否则报file not recognized: file format not recognized - 静态库路径写绝对路径更稳：
// #cgo LDFLAGS: /full/path/to/libxxx.a
微服务跑几天就 OOM，是不是 cgo 内存泄漏了
十有八九是 C 堆内存没释放。Go 的 GC 不管 C 分配的内存，所有 C.CString、C.CBytes、C.malloc 都得手动配对 C.free；C 函数内部 malloc 的内存，也得由 C 侧或 Go 侧约定好谁释放。
立即学习“go语言免费学习笔记（深入）”；
- 别依赖
runtime.SetFinalizer清理 C 内存——它不保证及时性，可能在 C 还在用时就触发 - 若 C 库需长期持有 buffer（如解码器输入区），必须设计引用计数或 ID 映射表，不能靠 Go 变量作用域自动清理
- 复用 C 内存时，用
C.malloc(C.size_t(n))分配，Go struct 中保存指针和容量，提供Close()方法统一C.free；确保只释放一次 - 传给 C 的指针，C 侧必须严格按传入长度操作；越界写会破坏相邻 Go 内存，Valgrind 也难查这类问题
边界划不清，问题就藏在看似正常的调用链深处——C 分配的内存，只能由 C 规则或明确约定的 Go 逻辑来释放，没有例外。
