报错“could not determine kind of name for c.xxx”是因为go编译器仅通过// #include "xxx.h"解析c符号，不读取.c文件；若头文件缺失、路径错误、未声明原型或含无效内联注释，即导致该错误。
为什么 C.xxx 报错 “could not determine kind of name”
因为 Go 编译器根本没看到函数声明——它不读 .c 文件，只认 // #include "xxx.h" 里写的原型。你写了 sum 在 math.c 里，但没在 math.h 中声明 int sum(int a, int b);，Go 就当它不存在。
-
math.h必须和main.go在同一目录，路径不能写成./include/math.h（cgo 默认不进子目录找） - 别用
/* int sum(int, int); */这种内联声明代替头文件——它无法被其他 Go 文件复用，也不支持宏展开或类型依赖 - 如果头文件里用了
#include <stdlib.h></stdlib.h>，必须显式写在// #include块里，否则 GCC 预处理失败，声明无效
如何让 go build 自动编译同目录下的 .c 文件
只要结构对，不用额外 flag，go build 就会自动发现并编译同包目录下的 .c 文件，和生成的 cgo stub 一起链接。
- 确保
.c和.go文件在同一目录、同一 Go 包下（比如都放在./mylib/） -
.c文件中必须#include "xxx.h"，且头文件里已正确定义函数原型 - 不要把
.c放进internal/或vendor/子目录——cgo 不递归扫描 - Windows 下注意路径分隔符：用
"math.h"而非"math\h"，否则#include失败
C.CString 后忘了 C.free 会发生什么
不是“可能泄漏”，是 一定泄漏，而且泄漏的是 C 堆内存，Go 的 GC 完全看不见。
-
C.CString底层调的是malloc，分配的是 C 内存；不C.free(unsafe.Pointer(ptr))，这块内存永远不会还 - 正确写法必须配对：
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 时为什么总找到 .so
cgo 默认按 libfoo.so → libfoo.a 顺序搜索，即使同目录有 .a 也不会用——除非你明确告诉它。
- 强制静态链接：
// #cgo LDFLAGS: -L./libs -static -lfoo（Linux）或完整路径：// #cgo LDFLAGS: ./libs/libfoo.a - macOS 上需额外加：
// #cgo LDFLAGS: -Wl,-force_load,./libs/libfoo.a，否则 archive 中未引用的符号会被 strip - 交叉编译时，静态库必须是目标平台 ABI 编译的，比如
darwin/arm64的库不能给linux/amd64程序用 - 检查库是否真存在：
file ./libs/libfoo.a看架构，ar -t ./libs/libfoo.a看符号表里有没有你要的函数
实际项目里最常卡住的不是语法，而是头文件路径拼错、.c 文件没放对位置、或者 C.CString 分配后没配对 C.free——这三处出问题，基本就是 90% 的 CGO 报错来源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
