<p>Go调用C代码是编译期静态链接，非松耦合；cgo仅识别紧贴import "C"上方的/ /注释块，空行或Go语句会使其失效；C函数需声明与实现共存或显式引入.c文件；内存管理、struct/数组传参、跨平台类型须严格遵循C规则。</p>
Go 调用 C 代码不是“调用外部库”那种松耦合方式，而是 cgo 在编译期把 C 代码（或其符号）静态链接进最终二进制——undefined: C.xxx 或 undefined reference to 'xxx' 这类错误，90% 都不是语法写错了，是 cgo 根本没看到 C 的声明，或根本没找到 C 的实现。
/* */ 注释块位置和格式必须严格对齐
cgo 只解析紧贴 import "C" 上方、且用 /* */ 包裹的注释块；任何空行、// 注释、Go 语句插入其中，都会让整块 C 代码失效。
-
/* #include <stdio.h> void f() { puts("ok"); } */✅ 有效 -
// #include <stdio.h>❌ 不会被识别为 C 代码 -
/* #include <stdio.h> */\n\nimport "C"❌ 中间有空行 → C 函数不可见 -
var x = 1\n/* #include ... */\nimport "C"❌ Go 语句在注释块前 → 整块被跳过
C 函数未定义：检查声明与实现是否分离
undefined reference to 'sumUp' 表示 cgo 看到了 sumUp 声明（比如在 #include "math.h" 里），但链接时找不到它的定义。cgo 不会自动编译同目录下的 .c 文件，除非你显式包含它，或确保它被构建系统捕获。
- 若用内联方式：把实现也写进
/* */块里，例如/* #include <stdio.h>\nint sumUp(int a, int b) { return a + b; } */ - 若用独立
.c文件：文件必须和.go同一包路径，且不能重名冲突（如math.go和math.c可以共存） - 若用预编译库：必须配
// #cgo LDFLAGS: -L/path/to/lib -lmath，且确保libmath.a是目标平台 ABI 编译的
C.CString 和 C.GoString 的内存归属必须手动理清
Go 字符串和 C 字符串内存模型完全不同，错配就会崩溃或泄漏——这不是 GC 能兜住的问题。
立即学习“go语言免费学习笔记（深入）”；
-
C.CString(s)分配 C 堆内存，返回*C.char，必须配对C.free(unsafe.Pointer(ptr))；漏掉就是 C 内存泄漏 -
C.GoString(cstr)复制内容到 Go 堆，返回新string，但cstr指向的原始内存仍归 C 管，你不释放它，它就一直占着 - 若 C 函数返回栈上字符串（如
char buf[64]; strcpy(buf, "hi"); return buf;），直接传给C.GoString会读野指针；必须先C.CString拷贝一份再用 - 跨 goroutine 传
*C.char时，确保 C 内存生命周期覆盖全部使用点；别依赖局部变量作用域
struct 和数组传参必须按 C 规则取地址
Go 的 struct 和 C 的 struct 布局不兼容，字段偏移、填充、对齐全由 C 编译器决定。手写 Go struct 去“模拟”几乎必错。
- 一律用
C.struct_foo，字段名和类型由 cgo 自动生成，不要自己定义 - 传数组给 C 函数：必须传
&cArray[0]（即首元素地址），不能直接传cArray（Go 不允许对数组变量取地址） - 若 C 函数要修改 struct 内容，必须传
&cStruct（即*C.struct_foo），传值只会改副本 - 跨平台注意：
C.int是 C 的int，在不同系统可能是 32 或 64 位；需要确定宽度时，用C.int32_t等固定宽度类型
最常被忽略的一点：cgo 不是透明桥接，它是编译期深度嵌入。一旦出问题，得从「cgo 是否解析了这段 C」开始查，而不是直接看 Go 侧调用有没有写错——因为 C.xxx 根本不存在时，Go 编译器连报错都报不到函数体里。
