Go 1.16+ 的 plugin 包已弃用，仅支持 Linux，Windows/macOS 因底层依赖 ELF 机制而不可用；推荐用 go:embed + exec.Command 子进程通信或接口注册表实现跨平台、安全的“伪动态”插件。
Go 1.16+ 中 plugin 包不支持 Windows 和 macOS（仅 Linux）
Go 的 plugin 包从设计上就只在 Linux 上可用，Windows 和 macOS 下构建会直接报错：build constraints exclude all Go files。这不是配置问题，而是底层依赖 ELF 动态符号解析机制。如果你的目标平台不是 Linux，这条路走不通——别浪费时间改 GOOS 或加 build tag。
用 go:embed + runtime/exec 模拟延迟加载逻辑
实际业务中所谓“延迟加载插件”，往往只是想避免启动时加载全部功能模块、节省内存或按需启用特性。这时更可靠的做法是把插件编译为独立可执行文件（GOOS=linux GOARCH=amd64 go build -o plugin-auth），主程序用 exec.Command 调用它，通过 stdin/stdout 交换 JSON 或简单文本协议。
- 插件二进制必须静态链接（
CGO_ENABLED=0 go build），否则部署时缺 libc 会失败 - 主程序启动插件前先检查
os.Stat(pluginPath)，不存在就跳过或报错提示 - 建议加超时控制：
exec.CommandContext(ctx, path).CombinedOutput()，避免插件卡死拖垮主流程 - 不要用
syscall.Exec替换进程 —— 它会终止当前 Go runtime，无法回收 goroutine 和 finalizer
用接口 + init() 注册表实现软插件化（推荐）
绝大多数 Go 服务不需要真正动态 dlopen，只需要“逻辑上可插拔”。标准做法是定义统一接口（如 type Plugin interface{ Init() error; Handle(req interface{}) error }），各插件包在自己的 init() 函数里调用全局注册函数：
// auth/plugin.go
func init() {
RegisterPlugin("auth", &AuthPlugin{})
}
主程序启动时遍历已注册插件名，按需调用 Init()；运行时根据请求类型查表分发。这种方式完全静态链接，跨平台，且能被 Go 工具链（如 go list -f '{{.Deps}}'）分析依赖。
立即学习“go语言免费学习笔记（深入）”；
- 注册表用
map[string]Plugin+sync.Once保护写入，避免并发注册 panic - 插件包不被 import 就不会触发
init()—— 可用构建 tag 控制是否包含某插件：//go:build with_auth - 注意：如果插件依赖大量第三方库，而主程序不直接引用，要显式加
_ "github.com/xxx/plugin"到 main.go，否则会被 linker 剔除
CGO + dlopen 真动态加载（仅限 Linux，慎用）
极少数场景（如兼容 C 生态的硬件驱动桥接）需要真实 dlopen，就得启 CGO 并手动绑定。核心是用 C.dlopen 加载 so，C.dlsym 查符号，再转成 Go 函数指针。但这绕过了 Go 的内存管理和调度模型：
- so 文件必须用
gcc -shared -fPIC编译，且导出符号要用__attribute__((visibility("default"))) - 不能在 so 里创建 goroutine 或调用 Go 运行时函数（如
println、make），否则崩溃 -
C.free必须由调用方负责释放 C 分配的内存，Go 的runtime.SetFinalizer对 C 内存无效 - 调试困难：gdb 看不到 so 里的 Go 符号，pprof 采样也常丢失帧
这种方案一旦上线，升级插件 so 就得重启主进程（因为 dlopen 不支持热替换），和“延迟加载”的初衷已有偏差。
