go plugin包在windows上完全不可用，因底层依赖elf/mach-o动态链接机制，而windows使用pe/coff格式且go官方未实现对应抽象，调用plugin.open必返回errnotsupported。
plugin 包在 Linux/macOS 上可用，但 Windows 下**完全不可用**——这不是配置问题，是 Go runtime 层面的设计限制，调用 plugin.Open 会直接返回 ErrNotSupported。
为什么 plugin.Open 在 Windows 上始终失败
Go 的 plugin 包底层依赖 ELF 动态链接机制（Linux）或 Mach-O（macOS），而 Windows 使用 PE/COFF 格式，且 Go 官方从未实现对应加载抽象。即使你用 go build -buildmode=plugin 编译出 .dll，plugin.Open 仍会 panic 或返回错误。
- 错误现象：
plugin.Open("./xxx.dll"): not supported - 兼容性影响：跨平台项目若依赖
plugin，Windows 开发者无法本地调试插件逻辑 - 替代思路：Windows 用户必须改用接口+文件系统注册、HTTP 插件服务、或进程间通信（如 gRPC）
plugin.Open 后必须立刻检查 nil
Open 操作失败时可能返回非 nil 的 *plugin.Plugin，但内部字段未初始化，后续调用 Lookup 会 panic。
- 正确做法：
p, err := plugin.Open(path); if err != nil || p == nil { log.Fatal(err) } - 容易踩的坑：忽略
p == nil判断，直接p.Lookup("New")→ 空指针 panic - 原因：某些构建环境（如 CGO_ENABLED=0）下 Open 可能静默失败并返回 nil 插件句柄
插件导出符号必须是包级变量或函数，不能是方法
Go 插件不支持导出结构体方法，只能导出顶层符号（函数、变量）。常见误写：var Instance Plugin 是对的，但 func (p Plugin) Do() {} 无法被 Lookup 找到。
- 正确导出示例：
var New func() interface{}或func GetPlugin() PluginInterface - 接口定义需放在主程序与插件**共用的独立包**中（如
github.com/your/app/pluginiface），否则类型不匹配 - 参数差异：插件里不能引用主程序私有包路径，否则编译时报
undefined: xxx
插件 Stop() 必须显式调用，否则 goroutine 和资源持续泄漏
插件若启动了后台 goroutine（如定时器、监听 channel）、注册了 HTTP handler、或打开了文件，plugin.Close() 不会自动清理这些状态。
- 必须约定插件暴露
Start()/Stop()方法，并由主程序严格按Start → ... → Stop → Close顺序执行 - 常见错误：只调用
Close()，导致 goroutine 无限运行、端口被占、日志刷屏 - 性能影响：未 Stop 的插件可能占用内存、fd、net.Conn 等资源，长期运行后 OOM
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
