c.xxx报错undefined，90%因cgo未识别声明或实现：仅解析紧贴import "c"上方的/ /块，空行、//注释或go语句会使其失效；头文件声明需匹配.c实现，且.c文件须显式链接或内联。
C.xxx 报错 undefined，90% 不是写错了函数名，而是 cgo 根本没看到 C 的声明或实现——它不读 .c 文件，只认紧贴 import "C" 上方的 /<em> </em>/ 注释块里的内容。
为什么 import "C" 后 C.sumUp 还是报未定义
根本问题不是头文件没加，而是 cgo 没真正解析到符号。常见断点有三个：
-
/* #include "math.h" */写成了// #include "math.h"—— cgo 只识别/* */块，//注释完全被忽略 -
/* #include "math.h" */和import "C"之间插了空行或 Go 语句（比如var x = 1）——整块 C 代码失效 - 头文件里声明了
sumUp，但math.c实现没被编译进最终二进制：cgo 默认不自动编译同目录下独立的.c文件，除非你把它显式#include进来，或确保构建系统能捕获它（如文件名匹配、无重名冲突）
用内联方式还是分离 .c 文件更稳妥
对私有轻量逻辑，直接内联最省事；对复用性要求高或已有成熟 C 库，分离更可控。
- 内联写法：
/* #include <stdio.h>\nint sumUp(int a, int b) { return a + b; } */</stdio.h>—— 所有声明+实现都在一块，go build一次过，适合原型或小工具 - 分离写法：把
sumUp实现放在math.c，头文件math.h放同一目录，Go 文件里只写/* #include "math.h" */—— 必须保证math.c和math.go在同一包路径下，且不能叫math.go和math.c（Go 会认为是重名冲突，跳过 .c 编译） - 别用
#include "math.c"—— GCC 允许，但可读性差、无法被其他 Go 文件复用、调试信息混乱
C.CString 忘记 C.free 会怎样
不是“可能泄漏”，是确定泄漏，而且 Go 的 GC 完全看不见那块内存。
-
C.CString("hello")底层调的是malloc，分配的是 C 堆内存，生命周期由你全权负责 - 正确配对写法必须是：
cstr := C.CString(s); defer C.free(unsafe.Pointer(cstr)) - 如果 C 函数返回
*C.char（比如内部malloc出来的），你也得自己C.free—— 除非文档白纸黑字写 “caller must not free” - 别把
C.CString结果存进全局 map 或结构体字段里：defer失效，生命周期难追踪，泄漏几乎必然发生
链接 libxxx.a 时为什么总 fallback 到 .so
cgo 默认按 libxxx.so → libxxx.a 顺序搜索，即使你放了 .a，它也优先选动态库。
- 强制静态链接：用完整路径代替
-lxxx，例如// #cgo LDFLAGS: /path/to/lib/libxxx.a - macOS 需额外加
-Wl,-force_load,/path/to/libxxx.a，否则 archive 中未引用的符号会被 strip 掉 - 交叉编译时（如 darwin/amd64 → linux/arm64），
libxxx.a必须是目标平台 ABI 编译的，否则报file format not recognized - 依赖链要列全：
-lssl -lcrypto不能只写-lssl，顺序也不能反（被依赖的放后面）
实际项目里最常被绕开、最后又花半天排查的，是 C 函数返回栈上字符串（比如 char buf[64]; strcpy(buf, "ok"); return buf;）——这时直接 C.GoString(cstr) 会读野指针，必须先 C.CString 拷贝一份再传。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
