plugin.open跨平台基本不可用，因它依赖go编译器强绑定abi，要求主程序与插件go小版本、goos/goarch、cgo_enabled、go111module及goroot完全一致，且windows不支持；真正可行方案是buildmode=c-shared导出c abi接口供外部调用。
plugin.Open 在跨平台场景下基本不可用，Windows 完全不支持，Linux/macOS 也极度脆弱；真正可行的跨平台方案是用 buildmode=c-shared 导出 C ABI 接口，再由宿主语言（如 Python、C、Java）调用——Go 本身不负责“加载”，只负责“被加载”。
为什么不能用 plugin.Open 做跨平台动态库加载
它不是通用动态加载器，而是 Go 编译器强绑定的 ABI 绑定机制，依赖太多隐式一致性条件：
-
plugin.Open要求主程序和插件使用完全相同的 Go 小版本（如 1.22.2 vs 1.22.3 就 panic） - 必须关闭模块系统：
GO111MODULE=off，且插件源码得放在$GOPATH/src下 -
CGO_ENABLED必须为 0（否则符号表冲突），但关掉后又无法调用任何 C 库 - Windows 上
plugin包根本不存在，调用直接编译失败 - 即使满足全部条件，
plugin.Lookup找不到函数大概率是因为签名字节级不一致：比如参数名不同、包路径不同（myapp.Configvsmain.Config）、interface{} 底层类型不一致
buildmode=c-shared 是唯一实际可行的跨平台出口
它生成的是标准 ELF/.dll 文件，遵循 C ABI，可被 Python ctypes、C 程序、Node.js 的 N-API、Java 的 JNI 等直接加载——Go 只管导出，不参与加载逻辑。
- 必须有
package main和空的func main() {} - 所有导出函数必须用
//export FuncName注释，且首字母大写 - 函数参数/返回值只能是 C 兼容类型：
C.int、*C.char、C.size_t，不能出现string、[]byte、struct（除非手动内存布局对齐） -
C.CString分配的内存必须由调用方释放（C 端 free，Python ctypes 需libc.free），否则泄漏 - Linux 下生成的
.so依赖目标机器有对应 Go 版本的运行时（libgo.so），静态链接效果有限，不推荐加-ldflags="-linkmode external -extldflags '-static'"
从 Go 调用外部 .so（比如 libc 或自定义 C 库）必须走 cgo，不能 dlopen
Go 没有原生 dlopen 支持。想在运行时加载任意 .so，唯一办法是用 cgo 封装 C 的 dlopen/dlsym：
- 必须在 Go 文件顶部写
// #cgo LDFLAGS: -ldl并#include <dlfcn.h></dlfcn.h> - 用
C.dlopen加载，C.dlsym查符号，C.dlclose卸载 - 传入的函数指针需用
C.CString转换字符串，返回的*C.char需手动C.free - 不能把 Go 指针（如
&myVar）直接传给 C 函数——会触发panic: call to C function with Go pointer argument - 该方式仅适用于调用 C 编写的库，**不能用来加载用
buildmode=c-shared生成的 Go .so**（它的符号不是 C ABI 可见的）
真正跨平台部署时最容易被忽略的点
不是语法或编译命令，而是运行时依赖的隐式传播：
- Windows 下用
c-shared生成的.dll依赖libwinpthread-1.dll和libgcc_s_seh-1.dll，目标机器没装 MinGW 运行时就直接报错 “The code execution cannot proceed because … was not found” - Linux 下
.so的RPATH默认为空，LD_LIBRARY_PATH必须显式设置，或用patchelf --set-rpath写死路径 - Python 调用时，
ctypes.CDLL("./libmath.so")失败，90% 是因为.so依赖的 Go 运行时找不到，而不是文件路径错 - macOS 的
.dylib还要处理@rpath和签名问题，codesign --force --deep --sign -常被跳过导致加载失败
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
