插件注册机制必须用函数指针而非接口类型，以实现真正解耦；应使用 map[string]func(http.Handler) http.Handler 存储插件，通过 init() 函数注册，加载顺序决定中间件包装顺序，热加载需依赖 plugin 包且严格匹配构建参数。
插件注册机制必须用函数指针而非接口类型
Go里常见误区是定义一个 Plugin 接口，让所有插件实现它，但这样会导致插件编译时就必须知道中间件的接口定义，破坏解耦。真正可行的是用函数签名统一入口，比如 func(http.Handler) http.Handler —— 这样插件只需导出一个符合该签名的函数，中间件不依赖插件代码，插件也不依赖中间件框架。
实际注册时建议用 map[string]func(http.Handler) http.Handler 存储，键为插件名（如 "auth"、"logging"），值为插件函数。注意：插件函数不能带闭包捕获外部变量，否则热加载时行为不可控。
- 插件文件需以
.go结尾，且必须包含init()函数来调用注册逻辑 - 避免在插件中直接调用
http.ListenAndServe或修改全局 mux，只做 handler 包装 - 如果插件需要配置，应通过环境变量或独立 config struct 传入，不要硬编码
插件加载顺序决定中间件执行链
Go 的 init() 函数执行顺序由包导入顺序决定，而插件通常以空白导入（_ "plugin/auth"）方式触发加载。这意味着：插件注册顺序 = 导入顺序 = 中间件包装顺序。你写的第一个插件，会是最外层 wrapper；最后一个，是最内层。
例如：_ "plugin/logging" 在前，_ "plugin/auth" 在后，则请求流为：logging → auth → handler。这点极易被忽略，导致日志里看不到认证失败细节（因为 auth 在 logging 外层，错误根本没进 logging）。
立即学习“go语言免费学习笔记（深入）”；
- 用
go list -f '{{.Deps}}' .查看实际导入顺序，验证插件加载顺序 - 若需动态控制顺序，可改用显式注册表 + 字符串优先级字段，而非依赖
init - 禁止在插件
init()中执行耗时操作（如连接数据库），会阻塞主服务启动
热加载插件必须绕过 Go 的包缓存机制
标准 go build 编译后的二进制无法动态加载新插件，因为 Go 不支持运行时重载已编译包。真要热加载，只能走 plugin 包（仅 Linux/macOS 支持），且要求插件和主程序用完全相同的 Go 版本、构建 tag、CGO 设置编译。
关键限制：plugin.Open() 加载的 so 文件，其导出符号必须是 unexported 类型（首字母小写）以外的函数或变量，且类型必须与主程序完全一致（包括包路径）。哪怕 time.Time 和 github.com/xxx/time.Time 都算不兼容。
- 插件编译命令必须加
-buildmode=plugin，且不能含main包 - 主程序需用
plugin.Lookup("Middleware")获取 symbol，再用.Interface().(func(http.Handler) http.Handler)断言 - 每次
plugin.Open()后必须调用plug.Close()，否则句柄泄漏
插件间共享状态只能靠 context.WithValue 或全局 sync.Map
插件之间不能直接通信，也没有“插件上下文”这种东西。常见需求如：auth 插件解析出用户 ID，logging 插件想打到日志里——唯一安全做法是把数据塞进 http.Request.Context()，用自定义 key（如 type userIDKey struct{}）避免冲突。
别用全局变量存插件状态，尤其在并发场景下。如果确实需要跨插件缓存（比如 token 解析结果复用），可用 sync.Map，key 设为 requestID（从 header 或生成）+ 插件名，而不是直接存 *http.Request 指针（可能已被 GC）。
- context key 必须是 unexported 类型，防止第三方插件误覆写
- logging 插件读取 context 值时，务必判空，避免 panic
- auth 插件写入 context 后，不应再修改该 request 的其他部分（如 body），否则影响后续插件
http.Request 和 http.ResponseWriter 的副作用边界——比如某个插件偷偷调用 w.WriteHeader()，后续插件就再也写不了 header 了。这事没法靠框架兜底，得靠约定和 Code Review。 
