Go插件机制不支持卸载、重载或生命周期控制，仅支持单次加载；plugin.Open后插件永久驻留内存，无法关闭或释放，其状态与goroutine随主进程存活至退出。
plugin 包本身不提供插件卸载、重载或生命周期控制能力——它只支持单次加载、符号查找和静态使用。一旦 plugin.Open 成功，插件就永远驻留在进程内存中，无法关闭、释放或再次加载同名文件。
这是 Go 插件机制的硬性限制，不是使用姿势问题。
plugin.Open 后插件就“活”着，没法关
-
plugin.Open返回的*plugin.Plugin结构体里没有Close、Unload或类似方法 - 插件的
init函数在首次Open时执行一次，之后不会再触发；main函数根本不会运行 - 操作系统层面，.so 文件被
mmap进进程地址空间后，Go 运行时不提供解除映射（unmap）的接口 - 尝试重复调用
plugin.Open同一路径，会返回缓存的已加载实例，而非新加载
这意味着：
- 插件变量/函数状态会持续累积（比如全局计数器、缓存 map）
- 插件中启动的 goroutine、监听的 channel、打开的文件句柄，全部随主进程存活，无法回收
- 若插件 panic 或内部出错，只能靠主程序提前防御，无法“重启插件”
为什么不能 reload？共享库加载机制决定的
- Go 的
plugin依赖底层dlopen（Linux/macOS）或LoadLibrary（Windows），但 Go 标准库没暴露 dlclose 调用 - 即使手动调用
dlclose，也无法安全释放：Go 运行时可能仍持有插件内分配的内存指针、runtime 类型信息、goroutine 栈帧引用等 - 官方明确文档指出：“Plugins cannot be unloaded or reloaded.”
所以：
立即学习“go语言免费学习笔记（深入）”；
- 不要设计“热更新插件配置后 reload”的逻辑
- 不要把插件当轻量服务模块来管理（那是
os/exec+ IPC 或 gRPC 的场景） - 如果真需要隔离与销毁，必须用子进程方式启动插件二进制，而非
plugin加载
替代方案：什么时候该放弃 plugin？
以下情况建议直接换技术路线：
- 需要插件启停、升级、故障隔离 → 改用
os/exec.Command启动独立进程，通过 stdin/stdout 或本地 socket 通信 - 插件需访问主程序未导出类型或泛型实例 →
plugin无法跨编译单元识别类型，会报"symbol not found" or "incompatible type" - 多版本插件共存（如 v1/v2 同时加载）→
plugin对路径敏感，且类型不兼容，极易 crash - 构建环境不可控（如交叉编译、CGO disabled）→
plugin要求 CGO enabled 且目标平台支持动态链接
插件的“生命周期”实际就是：从 plugin.Open 成功那一刻起，到整个 Go 进程退出为止。中间没有任何可控节点——这不是遗漏的功能，而是设计取舍。真正需要精细生命周期管理的场景，plugin 从一开始就不该是首选。
