Go plugin 仅支持 Linux/macOS，Windows 完全不支持；主程序与插件须同 Go 版本、构建参数及依赖版本；导出符号须为首字母大写的包级变量或函数，且类型具体；plugin.Open 后必须检查 Lookup 错误。
Go plugin 必须用 Linux/macOS，Windows 直接不支持
Go 的 plugin 包从设计上就只支持 ELF（Linux）和 Mach-O（macOS）格式，Windows 的 PE/COFF 不在支持范围内。哪怕你用 GOOS=windows 编译主程序，只要尝试 plugin.Open()，就会立刻 panic："plugin: not implemented on windows"。
常见错误现象：在 Windows 上写完 plugin.Open("xxx.so") 后编译通过，一运行就崩溃，还误以为是路径或符号问题——其实根本没进加载逻辑。
- 开发阶段别在 Windows 上验证 plugin 流程，换 Linux/macOS 虚拟机或 WSL2（注意不是 WSL1）
- CI/CD 中若需测试 plugin，必须指定
ubuntu-latest或macos-latest运行器，windows-latest会静默失败 - 交叉编译无意义：
GOOS=linux go build -buildmode=plugin产出的.so文件不能在 macOS 上加载，反之亦然
主程序和 plugin 必须用完全相同的 Go 版本和构建参数
Go plugin 本质是共享运行时符号，一旦主程序和 plugin 的 runtime、reflect 等包 ABI 不一致，plugin.Open() 就会返回 "plugin was built with a different version of package xxx" 错误。
这不是版本号“看起来一样”就行的问题——比如都用 go1.21.6，但一个用 go build，另一个用 go build -gcflags="-l"（禁用内联），ABI 也可能错位。
立即学习“go语言免费学习笔记（深入）”；
- 确保两者都用同一份
GOROOT和GOVERSION，推荐用go version和go env GOROOT逐项比对 - plugin 编译命令必须显式加
-buildmode=plugin，且不能带-ldflags="-s -w"（剥离符号后 plugin.Open 可能找不到导出函数） - 主程序编译时避免加
-trimpath，否则 plugin 中的文件路径信息不匹配，某些调试场景下会触发奇怪的 panic
导出符号必须是首字母大写的包级变量或函数
Go plugin 只能暴露顶层、可导出（即首字母大写）、非接口类型的标识符。像 var MyHandler = http.HandlerFunc(...) 可以，但 var handler = ... 或 type Plugin interface{...} 不行。
容易踩的坑是以为 “导出 struct 方法” 可以直接调用——不行。你只能导出函数或变量，如果想暴露行为，得把方法包装成函数：
// plugin.go
package main
import "net/http"
var MyRoute = http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("from plugin"))
})
// ❌ 下面这行无效：method 不是包级符号
// var _ = (*MyPlugin).ServeHTTP
- 导出变量类型必须是具体类型，不能是接口（如
var PluginImpl Plugin会报错 "cannot export interface value"） - 如果要用结构体，得导出指针变量：
var Instance = &MyPlugin{}，然后在主程序里用plugin.Lookup("Instance").Interface().(*MyPlugin) - plugin 内部 import 的第三方包（如
github.com/sirupsen/logrus）必须和主程序完全一致，否则plugin.Open()会因类型不匹配失败
plugin.Open() 后必须检查 error，且不能忽略 Lookup 返回的 error
plugin.Open() 成功只代表文件加载进内存，不代表所有符号都可用。plugin.Symbol 查找失败才是常见 runtime 问题源头，错误信息通常是 "symbol not found" 或 "no symbol Table"。
典型场景：导出变量名拼错、plugin 编译时没加 -buildmode=plugin、主程序用了 go run（而非先 go build）导致工作目录混乱。
- 永远用
if sym, err := p.Lookup("MyRoute"); err != nil { ... }判断，不要假设 Lookup 一定成功 - 查到 symbol 后，务必用
sym.Interface()转成具体类型，不能直接传给需要接口的地方——Go 不会自动做 interface 转换 - plugin 加载后无法卸载，进程退出前它一直占内存；反复
Open/Lookup同一文件不会重复加载，但多次Open不同文件会累积内存，这点常被忽略
plugin 是 Go 里少有的“破坏类型安全”的机制，ABI 兼容性、符号可见性、平台限制这些点环环相扣，漏掉任意一环都会在运行时崩，而不是编译时报错。
