能调，但必须走cgo约定路径：嵌入C声明、显式类型转换、手动内存管理；C.some_func报undefined主因是Go未看到声明，cgo只认#include块内可解析原型，不读.c文件，需头文件同目录且含完整声明，C++库须extern "C"包裹，C.CString必须配对C.free，静态库链接需明确指定路径与架构。
能调，但必须走 cgo 的约定路径——不是“Go 调 C”，而是“Go 文件里嵌入 C 声明 + 显式转换 + 手动内存管理”。绕开任何一环，轻则编译失败，重则运行时崩溃或内存泄漏。
为什么 C.some_func 总是报 “undefined”？
根本原因不是函数没写，而是 Go 编译器压根没看到它的声明。cgo 不读 .c 文件，只认 #include 注释块里 C 编译器能解析的原型。
-
/* #include "mylib.h" */必须存在，且mylib.h得和 .go 文件在同一目录；头文件里必须有int some_func(int a);这类完整声明，不能只写/* int some_func(); */内联注释 - 如果头文件依赖
<stdlib.h>等系统头，得显式写进注释块：/* #include <stdlib.h> #include "mylib.h" */ - C++ 库必须用
extern "C"包裹声明，否则函数名被 mangling，C.some_func就消失 - 独立的
.c文件不会被自动编译；要么把实现代码塞进/* */注释块里，要么用// #cgo LDFLAGS: -lmylib链接已编译好的库
C.CString 和 C.GoString 怎么配对才安全？
字符串是最容易出事的环节：Go 字符串不以 \0 结尾、底层内存不保证长期有效，C 函数直接收 string 会崩。
- 传入 C：必须用
C.CString(s)分配新内存并复制内容，结尾自动加\0；用完立刻C.free(unsafe.Pointer(ptr))，漏掉就是 C 堆内存泄漏 - 返回值是
*C.char：先判断来源——若指向常量字符串（如return "ok";），可直接C.GoString(cstr)；若来自malloc或strdup，你得自己C.free - 别把
C.CString结果存全局变量或 map 里，defer失效，生命周期难追踪 -
C.GoString返回的是 Go 堆副本，它不释放原始 C 内存；哪怕你刚调完C.GoString，原始cstr还得你自己管
链接静态库 libxxx.a 为什么总找不到符号？
cgo 默认优先找动态库（.so/.dll），即使同目录有 .a 也不用——除非你明确告诉它要静态链接，且路径、名字、架构全对。
立即学习“go语言免费学习笔记（深入）”；
-
// #cgo LDFLAGS: -L./libs -lxxx中的-lxxx对应的是libxxx.a（Linux/macOS）或xxx.lib（Windows），不是xxx.a - 要强制静态：加
-static-xxx（GCC）或直接写绝对路径// #cgo LDFLAGS: ./libs/libxxx.a - macOS 上静态库需额外加
-Wl,-force_load,./libs/libxxx.a，否则未引用的符号会被 strip 掉 - 交叉编译时，
libxxx.a必须是目标平台 ABI 编译的（比如 darwin/arm64 的库不能给 linux/amd64 用），否则报file format not recognized
调用带 argv 参数的 C 函数要注意什么？
别试图直接调 main——Go 运行时自己生成了 _cgo_main.c 里的 main，符号冲突必炸。重命名 + 手动构造 argv 是唯一安全路径。
- C 端函数名必须改掉，比如
main→app_run，签名保持int app_run(int argc, char** argv) - Go 端构造
argv：每个字符串用C.CString，再用unsafe.Slice或&argv[0]取首元素地址传过去 - 每个
C.CString都得配对C.free，包括argv[0]；别依赖局部作用域，defer放在分配后立刻执行 - 如果 C 函数内部 malloc 了内存并返回指针，Go 层负责 free；如果返回栈上地址（如局部数组），
C.GoString会读野指针
最常被忽略的不是语法，而是内存所有权边界：C 分配的，Go 不管；Go 分配的，C 不能长期持有。跨语言调用里，谁 alloc 谁 free 这条线一旦模糊，问题就藏在运行时里，等压测或上线才爆发。
