Go plugin机制仅支持Linux/macOS，Windows完全不支持；主程序与插件须完全匹配Go版本、GOOS/GOARCH及CGO配置，否则plugin.Open直接panic。
Go 的 plugin 机制不是“运行时编译 Go 源码”，而是加载预编译的 .so 文件；它只在 Linux/macOS 生效，Windows 完全不支持，且主程序与插件必须用**完全相同的 Go 版本、GOOS/GOARCH、CGO 配置**编译，否则 plugin.Open 直接 panic。
为什么 plugin.Open 总是报 “invalid plugin format” 或 “not implemented on windows”
这是最常卡住开发者的起点。错误不是代码写错了，而是环境或构建链不匹配：
-
invalid plugin format：主程序和插件用了不同 Go 版本（哪怕只是1.22.3vs1.22.4），或插件编译时没加-buildmode=plugin，却误用了go build -o xxx.so -
not implemented on windows：Windows 下plugin包压根不可用，连 stub 都没实现，不是配置问题，是平台限制 - 即使在 Linux/macOS，若插件里用了
cgo，而主程序编译时CGO_ENABLED=0，也会失败——两者 CGO 状态必须一致
plugin.Lookup 找不到函数或变量的常见原因
导出符号看似简单，但 Go 对“导出”的定义比表面更严格：
- 函数/变量名首字母必须大写，且不能在非
main包中定义（插件文件必须是package main） - 必须有空的
func main() {}—— 缺少它会导致链接失败，.so文件虽能生成，但plugin.Open会静默失败或报错 - 类型不匹配：比如插件导出的是
var Handler http.Handler，主程序用sym.(http.Handler)断言，但主程序和插件引用的http包路径不同（如 vendor 冲突、模块 replace 不一致），断言就失败 - 符号是函数但忘了加
import "C"？不需要——只有带 C 交互才需要；纯 Go 插件不需要//export注释或import "C"
插件依赖的二进制兼容性怎么保障
插件不是独立进程，它和主程序共享运行时堆、GC、类型系统。这意味着：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 插件中用到的所有类型（包括
struct、interface）必须和主程序“完全相同”：同名、同字段顺序、同嵌入结构、同方法集——哪怕只是多一个未导出字段，sym.(MyInterface)就会失败 - 推荐做法：把插件要暴露的接口定义在**主程序导出的公共包里**（如
pluginapi），插件import它，主程序也import它；避免插件自己定义接口再让主程序去 cast - 不要在插件里直接使用
log.Printf或fmt.Println做日志——它们可能和主程序的 logger 冲突；改用主程序传入的回调函数或标准输出重定向
替代方案比硬扛 plugin 更现实
除非你明确控制部署环境（全是 Linux、Go 版本锁死、无跨团队协作），否则 plugin 很快会变成维护噩梦：
- RPC/HTTP：用
net/rpc或轻量 HTTP handler 启一个本地 listener，主程序通过 socket 调用，隔离彻底、调试方便、跨平台 - 子进程 + JSON：插件编译为普通可执行文件，主程序用
os/exec启动，stdin/stdout 通信，天然进程级隔离 - embed + codegen：对简单场景（如模板、规则脚本），用
embed把 DSL 或 Lua 字节码打包进主二进制，运行时解释，规避动态链接一切问题
真正难的不是写通第一个 .so，而是让插件在三个月后、换人维护、升级 Go 版本、新增依赖时还能加载成功——这点上，plugin 几乎没有容错空间。
