go plugin.open加载失败主因是路径错误或插件格式不符；symbol.lookup为nil多因导出不规范或类型不匹配；热加载panic源于全局状态未清理；windows下plugin包完全不可用，需改用ipc或构建时注入。
plugin.Open 加载失败：找不到 .so 文件或符号
Go 的 plugin.Open 不会自动搜索路径，必须传入完整、可访问的文件路径。常见错误是直接写 "myplugin.so" 而没加前缀，导致系统在当前目录找，但实际编译出的插件可能在 ./plugins/ 下，或者根本没被复制过去。
确保：
- 插件文件已存在且有可读权限
- 路径是绝对路径，或基于 os.Executable() 或 os.Args[0] 构造相对路径（比如 filepath.Join(filepath.Dir(os.Args[0]), "plugins", "auth.so")）
- Linux 下插件必须是 ELF 格式、动态链接、无主函数，且用 go build -buildmode=plugin 编译
- macOS 需额外加 -ldflags="-s -w"，否则可能因符号表问题加载失败
Symbol.Lookup 返回 nil：类型不匹配或未导出
plugin.Symbol 查不到变量或函数，90% 是因为 Go 的导出规则没满足：首字母必须大写，且不能是局部变量、闭包或未命名类型实例。
典型翻车点：
- 写了 var handler func() = ...（小写变量名）→ 查不到
- 用了匿名结构体 var Config = struct{ Port int }{8080} → 类型无法跨插件识别
- 在插件里定义了 type Router struct{...}，主程序却用 struct{Port int} 去断言 → 类型不兼容，.(*Router) panic
- 主程序和插件用的 Go 版本不一致（如 1.21 vs 1.22），底层 runtime 符号 ABI 可能微变，导致 Symbol 找到但类型断言失败
插件热加载时 panic：全局状态冲突或内存泄漏
多次调用 plugin.Open + Close 看似安全，但 Go 的 plugin 包不支持真正意义上的“卸载”——Close 只释放部分句柄，已注册的 goroutine、全局 map、net.Listener、日志 hook 等不会自动清理。
实际要稳住：
- 插件初始化逻辑必须幂等，避免重复注册 http handler 或启动 goroutine
- 不要在插件里调用 log.SetOutput 或修改 http.DefaultServeMux 这类全局单例
- 如果插件暴露了 Start() / Stop() 接口，主程序必须显式调用 Stop() 再 Close()，否则资源持续累积
- plugin.Open 后立刻检查 plugin.Plugin 是否为 nil，避免后续空指针 panic
Windows 下 plugin 包根本不可用
Go 官方明确不支持 Windows 的 plugin 模式：plugin 包在 Windows 上始终返回 ErrNotSupported。这不是配置问题，是设计限制——Windows PE 动态库加载机制与 ELF 不兼容，且 Go runtime 未实现对应抽象层。
替代方案只有两个：
- 改用进程间通信（IPC）：主程序起子进程跑插件，通过 stdin/stdout 或本地 socket 通信
- 改用接口+构建时注入：把插件逻辑写成符合约定接口的包，编译进主程序（用 build tag 控制），牺牲热加载换稳定性
- 第三方方案如 hashicorp/go-plugin 本质也是 IPC，不是真 plugin，别被名字骗了
只要目标平台含 Windows，就别碰 plugin 包。Linux/macOS 上能跑，不代表架构可移植。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
