能调，但必须手动写对动态库路径、头文件位置和链接参数；漏掉任意一环就会报 undefined reference 或 cannot find -lxxx；头文件需显式列在 // #include 块中，不能递归解析；C++ 头文件须封装为 extern "C" 接口；函数签名须与库导出符号完全一致；运行时需确保库可被加载，ABI 必须匹配目标平台。
能调，但必须手动把动态库路径、头文件位置、链接参数全写对；漏掉任意一环，undefined reference 或 cannot find -lxxx 就立刻报给你看。
头文件和符号声明必须显式出现在 // #include 块里
cgo 不会递归解析头文件依赖。哪怕 mylib.h 里写了 #include <stdlib.h>，只要没在 Go 文件的 // #include 块中显式写出，C.malloc 这类函数就直接报未定义。
- 所有用到的头文件，一行一个写进
// #include注释块，不能嵌套、不能用#include_next - C++ 头文件必须先封装成 C 接口（用
extern "C"），Go 文件里// #include的只能是那个带extern "C"的 .h，不是原始 .hpp - 函数声明必须与动态库导出符号完全一致：签名、大小写、const 修饰符都不能差——用
nm -D libfoo.so | grep func_name确认真实符号名
// #cgo LDFLAGS 必须指定动态库路径和名字
Linux/macOS 下，-lfoo 表示找 libfoo.so（或 libfoo.dylib）；Windows 下找 foo.dll，但需额外处理导入库（.lib）或 DLL 路径。
- 路径优先用
${SRCDIR}：比如// #cgo LDFLAGS: -L${SRCDIR}/lib -lfoo，避免硬编码/usr/local/lib - Windows 上若用 MinGW 编译，需提供
libfoo.dll.a导入库，并确保foo.dll在运行时能被找到（靠PATH或同目录放置） - macOS 链接 dylib 时，可能需加
-rpath @loader_path/lib让可执行文件运行时从相对路径找库
运行时找不到 .so / .dll 怎么办
编译通过 ≠ 运行成功。链接器只管“编译时能找到”，不管“运行时能不能加载”。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“go语言免费学习笔记（深入）”；
- Linux：设置
LD_LIBRARY_PATH=/path/to/your/lib，或把库拷到/usr/lib（不推荐）或用patchelf --set-rpath写死路径 - macOS：设置
DYLD_LIBRARY_PATH，或构建时加-rpath @executable_path/../lib - Windows：把
foo.dll放到可执行文件同目录，或加到系统PATH；若用 MSVC 工具链，注意是否需要vcruntime140.dll等运行时 - 验证方式：
ldd ./myapp（Linux）、otool -L ./myapp（macOS）、Dependency Walker（Windows）
C 字符串和内存生命周期必须自己管
C.CString 分配的是 C 堆内存，Go 不回收；C.GoString 返回的是 Go 字符串副本，但不释放原 C 指针指向的内存——这两点错一点，就是崩溃或泄漏。
- 传字符串给 C 函数：用
C.CString(s)→ 调用 → 立刻C.free(unsafe.Pointer(ptr)) - C 函数返回字符串：若返回栈上地址（如
return "ok";），可直接C.GoString；若返回堆上malloc的内存，必须由 Go 调用C.free，不能靠 C 层自动释放 - 跨 goroutine 传递
*C.char或unsafe.Pointer时，确保 C 内存存活时间覆盖全部使用点；别把局部变量地址传出去
最常被忽略的是：动态库的 ABI 必须匹配目标平台。交叉编译时，libfoo.so 必须是目标架构（如 aarch64-linux-gnu）编译出来的，否则 file not recognized 错误不会告诉你缺什么，只会说“格式不对”。
