根本原因是cgo只识别C风格符号，C++函数经name mangling后无法被找到，必须用extern "C"包裹声明并转为C接口。
不能直接调用 C++ 类或模板函数，必须通过 C 兼容接口桥接；否则 C.xxx 会报未定义，链接失败或运行时崩溃。
为什么 C++ 头文件加了 #include 还是找不到函数
根本不是头文件路径问题，而是 cgo 根本没“看见” C++ 符号——它只认 // #include 块里声明的、且被 C 编译器能解析的 C 风格接口。C++ 的 name mangling 会让 void calc_phash(const char*, int) 在符号表里变成类似 _Z10calc_phashPKci 的名字，cgo 找不到。
- 所有 C++ 函数声明必须用
extern "C"包裹，写在头文件里（不是 .cpp 文件里） -
// #include块中只能引入你手动加了extern "C"的头文件，不能只引原始 C++ 头 - 如果 C++ 库用了 STL（如
std::string、std::vector），绝不能直接暴露给 cgo；必须在 bridge 层转成 C 原生类型（const char*、int*、void*） - 检查是否漏了
#include <stdlib.h>或<string.h>：C++ bridge 函数里若用了malloc、strlen，这些头也得显式写进// #include块
如何安全封装 C++ 类供 Go 调用
Go 没有析构概念，也不能直接 new/delete C++ 对象，必须把生命周期控制权交还给 Go 层。典型做法是返回 void* 句柄，再由 Go 显式调用释放函数。
- bridge 头文件里定义：
typedef void* FooHandle，然后声明FooHandle foo_new(int)、void foo_free(FooHandle)、int foo_value(FooHandle) - bridge 实现（.cpp）里用
new创建对象，用static_cast<Foo*>(h)转回指针，确保foo_free内部调用delete - Go 层用
defer C.foo_free(h)管理资源，但注意：不能跨 goroutine 传h，除非 C++ 类本身线程安全 - 避免在 bridge 函数里抛 C++ 异常；统一用返回码（
int）或输出参数（char* error）传错误
链接 C++ 库时 -lstdc++ 和静态/动态选择的关键点
cgo 默认按 libxxx.so → libxxx.a 顺序找库，且不自动链接 C++ 运行时；漏掉 -lstdc++ 或选错链接方式，会报 undefined reference to `operator new(unsigned long)' 或 file not recognized。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- Linux/macOS 必须在
// #cgo LDFLAGS:末尾加-lstdc++（macOS 有时还需-lc++） - 要强制静态链接（比如避免部署时缺 .so），写完整路径：
// #cgo LDFLAGS: /path/to/lib/libopencv_core.a -lstdc++ - macOS 上链接静态 archive（.a）时，必须加
-Wl,-force_load,/path/to/lib.a，否则未引用的符号会被 strip 掉 - 交叉编译（如 darwin → linux）时，C++ 库必须是目标平台 ABI 编译的；用
file libxxx.a确认 architecture 匹配
CString / GoString 性能陷阱与替代方案
高频调用 C++ 库时，C.CString 和 C.GoString 是最大性能瓶颈，每次调用都触发堆分配 + 深拷贝，开销达 50–200ns，远超 C++ 函数本身执行时间。
- 传字符串给 C++：优先用
C.CBytes([]byte(s))+ 显式长度参数，跳过 UTF-8 验证和strlen - 接收 C++ 返回的字符串：如果 C++ 函数提供长度（如
int get_result(char* buf, int* len)），就用C.GoStringN(cstr, n)，别用C.GoString - 避免在循环里反复
C.CString：改用固定缓冲区（C.malloc分配一次，Go struct 里保存指针，Close 时C.free） - 如果 C++ 库支持 zero-copy 输出（如写入 caller 提供的 buffer），就在 Go 层预分配
make([]byte, cap)，转unsafe.Pointer(&buf[0])传过去
最易被忽略的是 C++ 对象析构时机和跨 goroutine 共享句柄——C++ 析构函数可能依赖 TLS 或全局状态，而 Go 的 goroutine 可能在任意 OS 线程上运行；若不确定，宁可每次调用都 new/free，也不共享句柄。
