Go plugin 包为什么不适合跨版本加载

Go 的 plugin 包能把一个用 -buildmode=plugin 构建的 Go 主包加载进正在运行的程序，但它不是“把任意版本的 .so 动态换进去”。官方文档明确提醒：宿主程序和插件必须用完全相同的工具链版本、构建标签、相关编译参数与环境变量构建，共享依赖还要来自完全相同的源码。只要你的发布流程要求插件独立升级、跨机器复用或跨版本加载，plugin 通常就不是合适的边界。

官方文档：https://pkg.go.dev/plugin

Go plugin 先解决什么问题

plugin 适合“宿主和扩展由同一套构建流程产出”的场景：插件导出函数或变量，宿主通过名字查找后直接调用，数据结构可以在同一进程中共享，少一层序列化。插件首次打开时，尚未初始化的依赖包会执行 init，但插件的 main 不会执行；插件只初始化一次，也不能通过 API 关闭。

这意味着它的边界很窄：插件文件、宿主可执行文件和它们的运行环境需要被当作一份整体交付。目标平台也有限，目前文档列出的支持平台是 Linux、FreeBSD 和 macOS。

跨版本加载为什么容易变成运行时崩溃

跨版本问题不是只有“Go 1.x 和 Go 1.y”这一项。可以把官方警告拆成下面的发布检查表：

因此，“插件昨天能加载”不能证明“新宿主可以加载旧插件”。当插件需要独立发版时，最难锁定的往往不是主模块版本，而是间接依赖、构建标签和构建机环境。官方文档还提醒，插件对 race detector 的支持较弱，初始化时机也更难推理。

同一套构建环境中的最小加载方式

如果你的场景确实接受强耦合，可以把宿主和插件放进同一构建流水线。插件需要是 main 包，并导出宿主要找的符号；宿主用 Lookup 拿到符号后再做类型断言：

# 在同一构建镜像、同一 Go 工具链中产出两份文件
go build -buildmode=plugin -o build/greeter.so ./plugin
go build -o build/host ./cmd/host

package main

import (
	"fmt"
	"plugin"
)

func main() {
	// Open 会触发插件依赖包的初始化；插件不能被关闭。
	p, err := plugin.Open("build/greeter.so")
	if err != nil {
		panic(fmt.Errorf("打开插件失败: %w", err))
	}
	// Lookup 返回符号，断言类型必须和插件导出的函数签名一致。
	symbol, err := p.Lookup("Greet")
	if err != nil {
		panic(fmt.Errorf("查找 Greet 失败: %w", err))
	}
	greet, ok := symbol.(func(string) string)
	if !ok {
		panic("Greet 的函数签名不匹配")
	}
	fmt.Println(greet("Go"))
}

上线前至少把 Go 版本、go env 关键值、构建 tags、依赖锁定文件和目标系统写入同一份构建记录。若其中任意一项来自人工临时切换，就不要把生成的 .so 交给另一条发布流水线。

要跨版本，优先把边界移到进程或协议

如果需求是“宿主先升级，插件稍后升级”，就应让两边通过稳定协议通信。静态编译把扩展源码纳入宿主构建，最容易复现；独立进程配合 stdin/stdout 或 Unix socket 可以隔离崩溃；RPC/HTTP 则把版本契约落到消息格式，代价是序列化、部署和错误处理。

判断标准很简单：若“共享内存带来的性能收益”不是硬要求，而“独立升级”是硬要求，就不要用 plugin 承担版本边界。把接口定义成可演进的请求与响应，通常比赌一组隐藏的运行时兼容条件更可维护。

常见问题

Go plugin 只要宿主和插件的主版本号一样就可以吗？

不可以。官方要求还涉及工具链的精确版本、构建标签、相关 flags、环境变量，以及公共依赖的完全相同源码。

plugin.Open 能反复加载不同版本的插件吗？

插件只初始化一次，而且不能关闭。它不适合在同一进程里反复替换版本。

为什么不用 plugin 做跨平台扩展？

官方文档列出的支持平台是 Linux、FreeBSD 和 macOS；如果目标包含其他系统，独立进程或协议方案更稳妥。

什么时候仍然值得使用 plugin？

当宿主和插件由同一构建组件统一产出，平台固定，公共依赖和构建环境可锁定，并且确实需要进程内共享数据时，可以把它作为受控的内部扩展机制。