Go Plugin 仅支持 Linux/macOS，因依赖 dlopen/dlsym 而 Windows DLL 机制不兼容，官方明确不支持；Windows 调用 plugin.Open 直接报 "plugin: not implemented on windows/amd64"。
Go Plugin 为什么只支持 Linux/macOS，Windows 上直接报错
Go 的 plugin 包底层依赖操作系统动态链接器（dlopen/dlsym），而 Windows 的 DLL 加载机制与 ELF 共享库不兼容——Go 官方明确不支持 Windows 下的 plugin。你在 Windows 上调用 plugin.Open 会立刻返回 "plugin: not implemented on windows/amd64" 错误。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 开发期必须在 Linux 或 macOS 环境编译和运行插件主程序；CI/CD 流水线也需对应平台镜像（如
golang:1.22-alpine） - 不要试图用 MinGW 或 WSL “绕过”——WSL 是 Linux 内核，可用；但原生 Windows 进程永远无法加载
.so - 若必须跨平台，改用进程间通信（如 gRPC、HTTP）或序列化函数调用（如
go-plugin库），而非原生plugin
buildmode=plugin 编译失败：undefined symbol 或 import path 不匹配
Go 插件不是普通包，必须用特定模式编译，且主程序与插件的 Go 版本、构建标签、甚至 GOPATH 结构都必须严格一致。常见错误是 plugin.Open 返回 "symbol lookup error: undefined symbol: main.init" 或类似提示。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 插件源码必须用
go build -buildmode=plugin -o plugin.so ./plugin编译，不能用go install或普通go build - 插件里不能 import 主程序的私有路径（如
myapp/internal/util），否则符号无法解析；公共接口应定义在独立模块（如myapp/pluginapi）并被双方 vendor 或 go.mod 共享 - 主程序和插件必须用完全相同的 Go 版本（包括 patch 版本，如 1.22.3），且不能启用不兼容构建标签（如
-tags netgo在一方启用、另一方未启用）
如何安全导出函数：必须用 func() 接口，不能用 struct 方法
Go Plugin 只能导出包级函数，且签名必须是可序列化的：参数和返回值只能是基础类型、指针、切片、map、channel 或 interface{}（但 interface{} 实际值不能含未导出字段）。你不能直接导出一个 struct 的方法，也不能导出闭包或匿名函数。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在插件中定义统一入口函数，如
func Init() pluginapi.Plugin，返回实现某个公共接口的实例 - 接口定义必须放在共享包中，且所有字段/方法名首字母大写（否则 plugin 无法反射访问）
- 避免在导出函数中传递含未导出字段的 struct 值（如
json.Unmarshal后直接传 struct），会导致 panic；优先用 map[string]interface{} 或显式定义导出字段的 DTO
plugin.Open 后忘记调用 plugin.Close，导致文件句柄泄漏
plugin.Open 会打开 .so 文件并将其 mmap 到内存，但 Go 不自动管理其生命周期。如果反复加载/卸载插件却不调用 plugin.Close，Linux 下会快速耗尽 RLIMIT_NOFILE，表现为后续 Open 失败或系统级 open too many files 错误。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个
plugin.Open必须配对defer p.Close()（注意：p 是*plugin.Plugin，不是文件路径） - 不能对同一个 .so 文件多次
Open后只关一次——每次Open都是独立句柄，必须各自关闭 - 热更新场景下，旧插件 Close 后，原函数指针立即失效，务必确保无 goroutine 正在执行其中代码（没有内置同步机制，需自行加锁或用原子状态控制）
插件最麻烦的从来不是怎么写，而是版本对齐、符号可见性、以及加载后谁来负责清理资源——这些细节一旦漏掉，问题往往出现在上线后，而且难以复现。
