-go build -buildmode=plugin 是唯一合法编译方式，用于生成符合go插件规范的elf共享对象；其他方式产出的文件plugin.open会报invalid plugin format。
go build -buildmode=plugin 是唯一合法编译方式
不加 -buildmode=plugin 的 go build 产出的是普通可执行文件或静态库，plugin.Open() 会直接报 invalid plugin format。这个参数不是可选的，是硬性开关——它触发 Go 编译器生成 ELF 共享对象，并嵌入插件专用的符号表与运行时元信息。
常见错误：用 go build -o plugin.so main.go 代替，或者误加 -ldflags="-shared"（那是 C 工具链的逻辑，Go 不认）。
- 插件源码不能有
func main()，包名也不能是main；必须是普通包，比如package auth - 必须启用
CGO_ENABLED=1，即使代码里没写任何import "C"；plugin包底层依赖 cgo 的动态链接基础设施 - 推荐显式指定输出路径，避免默认生成在当前目录：
go build -buildmode=plugin -o ./plugins/auth.so auth.go
路径必须绝对，相对路径会触发版本校验失败
plugin.Open("auth.so") 看似合理，但实际会从当前工作目录找文件，而更致命的是：Go 在打开时会把相对路径转为绝对路径，再用该路径参与构建环境指纹比对。若主程序和插件编译时工作目录不同，哪怕 Go 版本、依赖完全一致，也会 panic：plugin was built with a different version of package xxx。
- 正确做法是用
filepath.Abs()或基于二进制位置构造路径：filepath.Join(filepath.Dir(os.Args[0]), "plugins", "auth.so") - Linux 下可验证路径是否可达：
ls -l $(readlink -f ./plugins/auth.so)，确保不是 dangling symlink - 不要依赖
GOROOT或GOPATH环境变量来“猜”路径；插件加载不读这些
导出符号必须是包级、首字母大写、类型签名严丝合缝
plugin.Lookup("Process") 返回 nil，90% 不是拼写错，而是违反了 Go 插件的导出契约。它不支持方法、闭包、局部变量、匿名结构体，也不做类型兼容推导。
- 只接受包级变量或函数，且名字首字母大写：✅
var Version = "1.0"，✅func Init() error；❌func (p *Plugin) Start()，❌var handler = func(){} - 函数签名必须字节级一致：插件里是
func Process(s string) (int, error)，主程序断言就必须是sym.(func(string) (int, error))；多一个指针、少一个 error、包路径不同（如myproj/v2/logvsmyproj/log），都会断言失败 - 避免导出 struct 类型本身；推荐导出一个接口变量：
var Plugin PluginInterface，主程序只做一次sym.(PluginInterface)断言
Linux 是唯一可行平台，macOS 和 Windows 上 plugin 包形同虚设
Go 官方明确不支持非 Linux 平台的 plugin。这不是 bug，是设计决定：底层强依赖 ELF 格式和 dlopen 行为。macOS 的 Mach-O、Windows 的 PE，plugin 包连编译都过不了，运行时直接 panic：plugin.Open: not implemented on this platform。
- macOS 上即使绕过构建约束（比如改源码加
// +build darwin），运行时仍会 crash；-ldflags="-s -w"只能缓解符号表问题，不能解决架构鸿沟 - Windows 下
plugin包硬编码返回ErrNotSupported，无论你用什么命令编译 .so，plugin.Open都不会成功 - 跨平台需求请立刻放弃
plugin，转向进程间通信（gRPC/HTTP）、cgo 封装 dlopen（仅限调用 C 库）、或构建时注入（如go:generate+ 接口注册）
plugin.Open 就拒绝合作。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
