本文介绍如何在 go plugin 场景下实现依赖接口（如 logger）的变量初始化，避免插件硬编码具体实现，通过共享 store 包在主程序加载插件前注入工厂函数，使插件内全局变量可自然初始化。
本文介绍如何在 go plugin 场景下实现依赖接口（如 logger）的变量初始化，避免插件硬编码具体实现，通过共享 store 包在主程序加载插件前注入工厂函数，使插件内全局变量可自然初始化。
在 Go 插件（plugin 包）开发中，一个常见痛点是：插件包无法像普通可执行程序那样，在 init() 阶段完成依赖注入——因为插件的 init() 函数会在 plugin.Open() 时立即执行，而此时主程序尚未提供所需的依赖实例（如 Logger 实现）。若强行将初始化逻辑后移到导出函数（如 Init(f)）中，则需重构所有全局变量为延迟赋值，并手动调用初始化链，既破坏原有代码结构，又增加维护成本。
所幸，Go 的包级变量初始化机制与链接期行为为我们提供了一种更优雅、更符合直觉的方案：利用共享的“配置存储包”（store package）作为依赖传递的桥梁。该方案无需修改插件内部变量声明语法，保持 var dlog = logger.CreateLogger("mypackage") 这类惯用写法，同时彻底解耦插件对具体实现的依赖。
✅ 核心思路：提前注入 + 包级变量延迟求值
关键在于两点：
- 定义一个主程序与插件共同导入的轻量级 store 包，其中仅包含可变的工厂函数或实例变量；
-
主程序在
plugin.Open()之前完成 store 的初始化，确保插件init()执行时，store 中的函数已就绪； - 插件中直接使用
store.LoggerFactory("name")初始化全局变量——Go 的包初始化顺序保证该调用在init()期间安全执行。
? 示例实现
首先，定义统一的 Logger 接口（位于独立模块，如 mylogger）：
// mylogger/logger.go
package mylogger
type Logger interface {
Log(msg string)
}接着，创建共享 store 包（需被主程序和插件共同 import）：
// store/store.go package store import "mylogger" // LoggerFactory 是插件获取 Logger 实例的唯一入口 var LoggerFactory func(name string) mylogger.Logger
主程序在加载插件前，预先设置工厂函数：
// main.go
package main
import (
"fmt"
"plugin"
"store"
"mylogger"
"yourloggerimpl" // 假设这是你具体的 logger 实现
)
func main() {
// ✅ 关键：在 Open 插件前注入依赖
store.LoggerFactory = yourloggerimpl.CreateLogger
// 此时再打开插件，其 init() 中对 store.LoggerFactory 的调用将返回有效实例
p, err := plugin.Open("./mypackage.so")
if err != nil {
panic(err)
}
// 后续正常使用插件导出符号...
sym, _ := p.Lookup("DoWork")
sym.(func())()
}插件包（mypackage）则完全保持原有风格，无需任何初始化函数：
// mypackage/mypackage.go
package mypackage
import (
"fmt"
"mylogger"
"store"
)
// ✅ 全局变量直接初始化 —— 依赖已由主程序注入
var dlog mylogger.Logger = store.LoggerFactory("mypackage")
func init() {
dlog.Log("mypackage initialized") // 正常工作！
}
// 导出供主程序调用的函数
func DoWork() {
dlog.Log("doing work...")
}⚠️ 注意事项与最佳实践
-
store 包必须为纯数据容器：仅含变量声明，不含
init()函数，避免初始化顺序冲突； -
确保 import 路径完全一致：主程序与插件中
import "store"必须指向同一份源码（建议通过replace或 vendor 管理），否则 Go 会视为两个不同包； -
线程安全非必需，但需注意生命周期：
LoggerFactory是全局变量，主程序应确保在plugin.Open()前完成单次赋值；若需运行时切换，应加锁或改用原子操作； -
不适用于需要插件主动注册的场景：本方案是“主程序驱动注入”，若插件需反向注册回调，仍需额外设计（如导出
Register(...)函数）； -
替代方案对比：相比
facebookgo/inject等 DI 框架，本方案零依赖、零反射、零运行时开销，完美契合 Go Plugin 的静态链接约束。
✅ 总结
通过一个极简的 store 包桥接主程序与插件，我们以最小侵入性实现了依赖的延迟绑定：插件代码零改造、初始化语义不变、依赖关系清晰可控。这不仅是 Logger 场景的解法，更可推广至任意接口类型（如 DB, Config, HTTPClient），是 Go Plugin 架构中推荐的标准初始化模式。
