go plugin包非生产级方案，仅限linux/macos且要求严格匹配go版本、构建参数与符号abi；windows完全不支持，热加载易panic，类型断言易失败，推荐改用进程隔离+ipc或wasm+wazero方案。
plugin 包不是生产级插件化方案，它只在 Linux/macOS 上能跑通，且对构建环境、Go 版本、符号 ABI 有苛刻要求；Windows 下直接不可用，热加载会 panic，类型断言极易失败。
plugin.Open 失败：路径、格式、ABI 全都得对上
报 "no such file or directory" 不一定是文件不存在，更可能是：
– 插件没用 go build -buildmode=plugin 编译（缺这个参数，生成的是普通可执行文件）
– 路径不是绝对路径，或没基于 os.Args[0] 构造（比如写成 "plugins/auth.so"，但实际在 ./bin/plugins/）
– Linux 下插件依赖的 libc 或 Go runtime so 找不到（需确保 LD_LIBRARY_PATH 包含插件所在目录）
– 主程序和插件用了不同 Go 版本、不同 CGO_ENABLED 设置，或依赖模块哈希不一致（哪怕只差一个 replace，也会触发 "plugin was built with a different version of package xxx"）
Symbol.Lookup 返回 nil：导出规则和类型契约必须严丝合缝
查不到符号，90% 是因为：
– 函数或变量名首字母小写（var handler func() → 不导出）
– 导出了方法或结构体字段（func (p Plugin) Serve() 或 type Config struct{ Port int } → 插件不导出类型定义）
– 主程序用 interface{} 或匿名结构体去断言（sym.(struct{Port int})），而插件里是 type Config struct{...} → 类型不兼容
– 接口定义没放在独立模块里，主程序和插件各自 copy 了一份 type Processor interface{...} → 底层类型 ID 不同，断言失败
热加载后 panic：Close 不等于卸载，全局状态没人清理
plugin.Close() 在当前 Go 版本里基本是空操作，多次 plugin.Open() 同一路径会直接 panic。
真正危险的是插件里启动的 goroutine、注册的 http.DefaultServeMux、修改的 log.SetOutput —— 这些都不会随 Close() 消失。
必须做到：
– 插件暴露 Start()/Stop() 方法，主程序显式调用 Stop() 再 Close()
– 避免在插件中操作任何全局单例（尤其是 net/http、log、time/ticker）
– 初始化逻辑幂等（重复调用 Init() 不会重复注册 handler 或开新 listener）
跨平台或生产环境该用什么替代 plugin？
别硬扛 plugin 的限制。真实可用的路径只有两条：
– **进程隔离 + IPC**：插件做成独立可执行文件，主程序用 exec.Command 启动，通信走 stdin/stdout、本地 socket 或 HTTP/gRPC；好处是语言无关、ABI 无关、Windows 友好、崩溃不影响主进程
– **WASM + wazero**：用 //go:embed plugins/*.wasm 把插件字节码打进去，运行时用 wazero 加载执行；沙箱隔离、跨平台、无 Go 版本绑定，适合轻量逻辑（如策略计算、数据转换）
两者都绕开了 plugin 最致命的问题：它本质是 C 风格动态链接的 Go 封装，不是为现代微服务或 CLI 工具设计的插件机制。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
