Go编译共享库必须用-buildmode=c-shared，生成C兼容ABI的.so文件供C调用；导出函数需//export声明、参数返回值限C类型、须在main包中且含至少一个export函数、CGO_ENABLED=1为前提。
Go 编译共享库必须用 buildmode=c-shared
Go 本身不支持传统意义上的动态链接（如 C 的 dlopen 加载任意符号），但可通过 go build -buildmode=c-shared 生成带 C 兼容 ABI 的 .so 文件，供 C/C++ 程序调用。这不是“通用动态库”，而是 Go 运行时封装后的 C 接口桥接层。
关键限制：导出函数必须满足 C ABI 要求 —— 参数和返回值只能是 C 基本类型（C.int, C.char, *C.char 等），且函数名需用 //export 注释显式声明。
- 必须在
main包中编译，不能是普通包 - 必须有至少一个
//export函数，否则构建失败 - 不能使用
init()中触发 goroutine 或依赖未初始化的 Go 运行时（启动前调用会 crash） -
CGO_ENABLED=1是强制前提（默认开启，但交叉编译时易被关掉）
导出函数写法与常见错误
Go 导出函数不是靠首字母大写，而是靠 //export 注释 + C 函数签名。漏掉注释、签名不匹配、或返回 Go 字符串/结构体都会导致链接失败或运行时 segfault。
正确示例：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
package main
<p>/*</p><h1>include <stdio.h></h1><p>*/
import "C"
import "unsafe"</p><p>//export Add
func Add(a, b C.int) C.int {
return a + b
}</p><p>//export Hello
func Hello() *C.char {
return C.CString("hello from Go")
}</p><p>//export FreeString
func FreeString(s *C.char) {
C.free(unsafe.Pointer(s))
}</p><p>func main() {}
-
//export必须紧贴函数声明上方，中间不能有空行 - 返回
*C.char时，必须配套提供释放函数（C 侧调用free），否则内存泄漏 - 不能返回
string、[]byte、struct等 Go 类型；C 无法理解其内存布局 - 所有
C.*类型必须来自"C"伪包，不能用int替代C.int（大小/符号性可能不一致）
编译命令与产物说明
执行 go build -buildmode=c-shared -o libmath.so math.go 后，会生成两个文件：libmath.so 和 libmath.h。后者是自动生成的头文件，声明了所有 //export 函数，C 程序必须包含它。
-
libmath.so依赖系统 libc 和 Go 运行时（libgo.so等），但 Go 1.16+ 默认静态链接运行时，所以通常只依赖 libc - 若提示
undefined reference to `__cgo_...，检查是否漏了import "C"或CGO_ENABLED=0 - 交叉编译（如 Linux → ARM64）需确保
CC指向目标平台的 C 编译器，并设GOOS=linux GOARCH=arm64 - 用
ldd libmath.so查看实际依赖，确认无意外的 Go 动态依赖项
C 程序如何安全调用
C 侧不能直接 dlopen 后 dlsym 调用 —— Go 导出函数依赖 Go 运行时初始化。必须先调用 libmath.so 提供的 GoInitialize（由 Go 自动生成），再调用业务函数，最后可选调用 GoFinalize。
但更稳妥的做法是：让 Go 控制生命周期，在 main() 中完成初始化后，用 C. 调用 C 函数 —— 实际项目中，多数采用“Go 主程序 + C 插件”模式，而非反过来。
- 如果坚持 C 主程序加载 Go 库，务必在
dlopen后立即调用GoInitialize（该符号总存在，但未在.h中声明） - 多线程调用前，需确保 Go 运行时已启动且未退出；并发调用导出函数是安全的
- 传入的
*C.char若由 C 分配，Go 不负责释放；反之亦然 —— 内存归属必须严格约定 - Go 1.20+ 对
c-shared模式做了稳定性加固，但runtime.LockOSThread等仍可能干扰 C 主程序线程模型
真正麻烦的从来不是怎么编出 .so，而是 Go 运行时与宿主进程的生命周期对齐、错误传播（Go panic 无法跨语言传递）、以及 CGO 调用栈混杂后的调试难度 —— 这些不会在 go build 成功时暴露。
