go中注册表模式只需map加sync.rwmutex，无需复杂抽象；核心是线程安全的全局映射表，键名需统一处理，插件注册应在init阶段完成，类型断言须带ok检查，初始化时机与依赖管理才是关键。
注册表模式在 Go 里其实不需要“实现”，而是用 map + sync.RWMutex 就够了
Go 没有运行时类加载或反射注册机制，所谓“Registry 模式”在 Go 中本质是手动维护一个线程安全的全局映射表。强行套用 Java 或 C# 的注册表抽象，反而会引入不必要的泛型约束、接口膨胀和初始化顺序问题。
常见错误现象：panic: assignment to entry in nil map（忘记初始化 map）、concurrent map read and map write（没加锁）、插件注册后调用时返回 nil（键名大小写/空格不一致）。
- 注册表核心结构就是
var registry = sync.Map{}或var registry = Struct{ sync.RWMutex; m map[String]Interface{} }{m: make(map[string]interface{})}—— 前者适合只读多、写少；后者可控性更强，能自定义类型断言逻辑 - 注册函数不要返回错误，失败就 panic 或 log.Fatal：插件注册应在
init()阶段完成，运行时注册失败属于配置或代码错误，不该被忽略 - 键名统一用
strings.TrimSpace(strings.ToLower(name))处理，避免空格和大小写导致查不到
plugin.Open 加载动态库前必须确保符号导出且 ABI 兼容
Go 的 plugin 包不是通用插件系统，它依赖编译器生成的符号表和运行时 ABI，跨 Go 版本、跨 GOOS/GOARCH、甚至不同 -buildmode=plugin 参数都会导致 plugin.Open: plugin was built with a different version of package ...。
使用场景很窄：仅限 linux/macos 下，主程序与插件用完全相同的 Go 版本、相同 GOPATH（或模块路径）、相同构建标签编译。
立即学习“go语言免费学习笔记（深入）”；
- 插件文件必须用
go build -buildmode=plugin -o plugin.so ./plugin构建，不能用go install或普通go build - 导出符号必须是首字母大写的变量或函数，例如
var Factory = func() interface{} { return &MyService{} }，小写名无法被plugin.Lookup找到 - 插件内不能引用主程序的私有包路径（如
main或未发布模块），否则链接失败；建议把共享接口定义在独立模块中，主程序和插件都go mod require它
用 interface{} 做注册值类型时，断言失败比 panic 更危险
注册表存的是 interface{}，取出来直接强制类型断言（v.(MyPlugin)）一旦失败就会 panic。而插件系统往往需要容忍部分插件缺失或异常，不能因一个插件崩掉整个服务。
性能影响不大，但可维护性差：每次调用都要写两层判断，容易漏掉 ok 检查。
- 统一用带检查的断言：
if p, ok := registry.Load("auth"); ok { if auth, ok := p.(AuthPlugin); ok { auth.Do() } } - 更推荐封装一层：定义
type Registry struct{ mu sync.RWMutex; m map[string]any }，提供Get[T any](key string) (T, bool)方法，内部做类型检查，调用方不用重复写ok - 避免在注册时做类型检查（比如
func register[T Plugin](name string, v T)），Go 泛型实例化会在编译期爆炸式增长注册函数数量，实际没收益
真正决定插件化成败的是初始化时机和依赖图，不是注册表本身
注册表只是容器，真正的难点在于：插件什么时候加载？依赖的配置、日志、数据库连接从哪来？多个插件之间有没有启动顺序要求？这些问题不解决，注册表再漂亮也没用。
容易被忽略的点：init() 函数执行顺序不可控，不同包的 init 可能交错执行；插件依赖主程序提供的全局 logger，但 logger 初始化可能晚于插件注册。
- 把插件注册和初始化拆开：注册阶段只存工厂函数（
func() Plugin），启动时统一调用Create()并传入上下文、配置、依赖项 - 用
sync.Once控制全局依赖（如 DB 连接池）的首次初始化，插件工厂内部按需调用，而不是假设它已就绪 - 如果插件间有依赖（如 A 要用 B 提供的服务），注册表键名应体现层级，比如
"service.auth"和"service.cache"，启动时按字符串排序或显式声明依赖列表来控制顺序
注册表本身很简单，难的是让一堆彼此不认识的代码，在没有中心调度的情况下，靠约定协作起来。这个约定，得靠文档、工具链和早期验证来守住，不是靠设计模式名字撑场面。