C.some_func报undefined的根本原因是cgo仅解析import "C"上方注释块中显式声明且C编译器可直接编译的代码，不自动处理.c文件、不递归展开头文件、不识别C++ name mangling，所有依赖头文件必须逐行写入// #include块，C++库须用extern "C"包裹声明。
Cgo 不是“扩展能力边界”的魔法，而是把 Go 和 C 的内存模型、生命周期、错误处理强行接在一起的硬接口——用对了能撬动整个 C 生态，用错了连 panic 都报不出完整堆栈。
为什么 C.some_func 总是 undefined？
不是函数没写，是 cgo 根本没“看见”它。cgo 只解析 import "C" 上方注释块里能被 C 编译器直接编译的代码，不读 .c 文件，不递归展开头文件，也不理解 C++ name mangling。
- 头文件必须显式写进注释块：
/* #include "mylib.h" */，不能靠#include_next或条件宏 - 如果
mylib.h依赖<stdlib.h>，就得一起写：/* #include <stdlib.h> #include "mylib.h" */ - C++ 实现的库，头文件里必须包一层
extern "C"，否则C.some_func在链接时就消失 - Linux/macOS 下静态库名要写成
-lfoo（对应libfoo.a），不是foo.a；Windows 下是-lfoo对应foo.lib
C.CString 和 C.GoString 为什么总崩？
崩溃主因不是函数写错，是字符串生命周期失控：Go 字符串底层不以 \0 结尾，C 函数直接收 char* 就越界；C.CString 分配的内存 Go GC 不管，忘了 C.free 就泄漏；C.GoString 依赖 strlen 扫描，遇到中间 \0 就截断。
- 输入字符串优先用
C.CBytes([]byte(s))→ 返回unsafe.Pointer，再转(*C.char)，显式传长度，不扫描\0 - 循环里别写
defer C.free，会只释放最后一次分配的地址；改成cs := C.CString(s); ...; C.free(unsafe.Pointer(cs)) - 输出字符串，C 函数返回
char*且明确长度时，用C.GoStringN(cstr, n)，别用C.GoString(cstr) - 绝对不要把
C.CString结果存进 map、channel 或全局变量——defer失效，内存永远不回收
高频调用 C 函数性能为什么反而更差？
单次 C.some_func() 调用开销在 50–200 ns，看似微不足道，但一旦进循环，调度切换、ABI 适配、参数打包/解包、信号屏蔽等成本叠加，很快压倒 C 层计算收益。
立即学习“go语言免费学习笔记（深入）”；
- 避免
for _, v := range data { C.process_one(v) }这类模式 - 改用批量接口：把
[]float64转成(*C.double)(unsafe.Pointer(&data[0]))，一次传整块内存给 C 处理 - 若 C 库无批量 API，自己封装一层 C 函数做聚合，比 Go 侧循环调用安全且快得多
- 零复制传参可用
reflect.StringHeader提取Data地址，但必须确保 C 函数在 Go 调用返回前完成所有操作——不能长期持有指针
静态库 libalgo.a 死活链不上？
cgo 默认搜动态库（.so/.dylib），同目录放了 libalgo.a 也不会自动用，除非你明说“我要静态”，而且路径、名字、目标平台 ABI 全得对上。
-
// #cgo LDFLAGS: -L./libs -lalgo中的-lalgo指的是libalgo.a（Linux/macOS）或algo.lib（Windows） - macOS 强制静态需加
-Wl,-force_load,./libs/libalgo.a，否则 archive 里未引用的符号会被 strip - Linux 可用
-static-libalgo或直接写绝对路径：// #cgo LDFLAGS: /path/to/libalgo.a - 交叉编译时，静态库必须是目标平台 ABI 编译的，否则报
file not recognized: file format not recognized
最常被忽略的点不是语法怎么写，而是谁负责哪段内存、谁决定哪段生命周期、谁处理哪个信号——这些边界一旦模糊，panic 都可能发生在 C 堆里，Go 的调试器根本抓不到。
