plugin.open失败却无报错是静默失败，仅表示文件存在且格式合法，需检查-buildmode=plugin、cgo_enabled=1、elf共享对象类型、导出符号大写、//go:noinline、main包名、init逻辑及类型断言必须经reflect.valueof().interface()中转。
plugin.Open失败但没报具体错误
plugin.Open返回nil却不抛panic，这是最常被忽略的“静默失败”。它不等于加载成功，只是说明文件存在且格式合法，但ABI兼容性、符号导出、构建参数等还没校验。
- 先确认插件是否用
go build -buildmode=plugin编译——错用-buildmode=c-shared或普通go build都会导致Open后Lookup失败 - 检查
CGO_ENABLED=1是否启用：plugin强制依赖cgo，设为0会生成无效so - 用
file plugin.so验证文件类型：输出必须含“ELF”和“shared object”，不含“executable”或“statically linked” - Linux下可进一步用
readelf -d plugin.so | grep NEEDED看是否链接了libgo.so——缺失即非Go插件
Lookup返回nil但符号名明明写对了
拼写正确 ≠ 可被查到。Go反射只暴露导出符号，且编译器优化可能让符号消失。
- 确保符号首字母大写：
Handler可以，handler不行；PluginInstance可以，pluginInstance不行 - 加
//go:noinline注释到函数/变量定义上，防止内联导致符号被抹除 - 插件源码包名必须是
main，且整个插件项目只能有一个main包（否则go build -buildmode=plugin直接报错） - 检查插件中是否用了
init()注册逻辑——它在plugin.Open时已执行，但若注册失败，Lookup仍返回nil，需单独加日志验证
类型断言panic: interface conversion failed
这不是插件问题，是主程序反射调用方式错了。插件包路径和主程序包路径不同，Go认为它们是两个独立类型。
- 不能直接
sym.(MyPluginInterface)——即使接口定义一字不差，包路径不同就不是同一类型 - 必须经
reflect.ValueOf(sym).Interface()中转，再做断言：sym, _ := plug.Lookup("PluginInstance")<br>obj := reflect.ValueOf(sym).Interface()<br>if p, ok := obj.(MyPluginInterface); ok {<br> p.Init()<br>} - 漏掉
.Interface()这一步，99%会panic；更糟的是，有些场景下断言看似成功，实则操作的是副本，资源未真正初始化
热加载后内存持续上涨、goroutine泄漏
plugin.Close()是空实现，它不释放任何资源。所谓“卸载”是幻觉。
- 插件里启动的goroutine、注册的HTTP handler、log hook、全局map等，Close后依然存活
- 必须设计显式的
Stop()方法，并在plugin.Close()前手动调用——别指望系统自动清理 - 避免在插件中修改全局单例：
http.DefaultServeMux、log.SetOutput、time.AfterFunc等，这些无法被安全还原 - Init()必须幂等：重复调用不能注册重复路由或启动新goroutine，否则每次热加载都叠加一层
plugin.Open能卸载旧模块。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
