plugin.Open 在 Windows 上必然失败，别试了；Go 的 plugin 包因底层依赖 ELF/Mach-O 机制，与 Windows 的 PE/COFF 完全不兼容，runtime 层硬性屏蔽，调用必返回 ErrNotSupported 或 panic。
plugin.Open 在 Windows 上必然失败，别试了
Go 的 plugin 包在 Windows 上根本不可用，不是配置问题，是 runtime 层硬性限制。调用 plugin.Open("./xxx.dll") 会直接返回 ErrNotSupported 或 panic："plugin: not implemented on windows"。哪怕你用 go build -buildmode=plugin 强行生成了 .dll 文件，也无法加载。
原因很明确：Go 的 plugin 机制只支持 ELF（Linux）和 Mach-O（macOS）格式，完全不兼容 Windows 的 PE/COFF。这不是未来可能支持的“待办事项”，而是官方已明确放弃的设计边界。
如果你的项目要跑在 Windows 上——无论是开发、测试还是生产——必须立刻排除 plugin 方案。本地调试插件逻辑时卡在这一步，99% 是平台误判导致的徒劳编译。
Linux/macOS 下 plugin.Open 失败的三个高频原因
plugin.Open 报错但没明显提示？大概率栽在这三处：
立即学习“go语言免费学习笔记（深入）”；
- 路径不对：
plugin.Open("auth.so")默认在当前工作目录找，但插件实际在./plugins/auth.so。务必用绝对路径，或基于os.Args[0]构造：filepath.Join(filepath.Dir(os.Args[0]), "plugins", "auth.so") - 构建参数不一致：主程序和插件必须用**完全相同的 Go 版本、CGO 状态、-gcflags** 编译，否则报
"incompatible plugin"。CI 中常见主程序用 Go 1.22，插件用 1.21，一运行就跪。 - 符号没导出：Go 要求导出符号首字母大写，且不能是局部变量或匿名类型。写
var handler func()（小写）或var Config = struct{Port int}{8080}（匿名结构体），Lookup("handler")必然返回nil。
插件热加载后 goroutine 和资源不释放，怎么 stop？
plugin.Close() 不等于“卸载”——它只释放部分句柄，不会停掉插件里启动的 goroutine、关闭监听的 net.Listener、清理注册的 http.Handler，甚至不会重置全局 log 输出。后果是端口被占、fd 耗尽、日志刷屏、内存缓慢泄漏。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
真正能稳住的做法只有这一条路：
- 插件必须暴露
Start()和Stop()方法（比如返回error） - 主程序严格按顺序执行：
p.Lookup("Start").(func())()→ 业务使用 →p.Lookup("Stop").(func())()→p.Close() - 所有后台逻辑（定时器、channel 监听、HTTP server）都得封装进
Start/Stop，不能放在包 init 或变量初始化里
漏掉 Stop() 调用，等于给系统埋雷。尤其插件里用了 http.Serve 或 time.Ticker，不显式关，进程就永远卡着。
跨平台插件系统的唯一可行路径：IPC + 独立进程
想让插件在 Linux/macOS/Windows 全平台跑，又不想被 plugin 的 ABI 锁死，唯一稳健方案是把插件做成独立可执行文件，主程序用 os/exec 启动，走 HTTP/gRPC/Stdio 通信。
关键不在“怎么通”，而在“怎么控”：
- 插件启动后必须主动监听（如
--addr=:8081），主程序轮询端口就绪再发请求，避免竞态 - 每个插件进程启动时输出自身
PluginAPIVersion，主程序校验版本不匹配则拒绝加载 - 错误分层：子进程 exit code ≠ 0 → “插件崩溃”；HTTP 400 → “协议错误”；5s 超时 → “响应延迟”
- 接口定义必须收敛到独立包（如
github.com/your/app/pluginapi），主程序和插件都 import 它，避免类型不一致
真正的难点从来不是“怎么加载”，而是“怎么安全收尾”。一个没 Stop() 的插件，比一个加载失败的插件更危险——它安静地吃光资源，直到某天 OOM。
