插件兼容

Go 的 plugin.Open 不能当成“所有系统都支持的动态加载入口”。官方 plugin 包目前只支持 Linux、FreeBSD 和 macOS；在其他系统，或者构建时没有启用 CGO，调用通常会得到 plugin: not implemented。比较稳妥的做法是先把插件能力藏在一个业务接口后面，再把“动态实现”和“内置实现”做成两个可替换后端：插件可用时加载，插件不可用时只对明确允许降级的场景切换内置实现。

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

优雅降级不是忽略错误，而是把“插件是可选能力”写进接口和配置；如果插件本来就是核心业务，就应该让启动失败，而不是悄悄改用另一套逻辑。

先认清 plugin.Open 的平台边界

plugin 需要用 go build -buildmode=plugin 生成插件。它支持动态打开和符号查找，但插件只初始化一次，不能关闭；应用与插件还需要使用一致的工具链、构建标签、关键编译参数和公共依赖源码。也就是说，“当前系统是 Linux”只代表具备尝试条件，不代表这个 .so 一定能安全加载。

Go 标准库在不支持的系统或没有 CGO 时仍然提供了包的接口，但底层实现会返回 plugin: not implemented。因此不要把它当作网络错误重试，也不要通过字符串猜测操作系统来决定业务逻辑；应把这个错误归类为“动态后端不可用”，交给统一的加载策略。

先用接口隔离动态实现

业务代码只依赖稳定的接口，加载器负责把插件符号转换为接口实现。下面的示例假设插件导出一个 NewRunner 函数，插件与主程序都依赖同一个 contract 包；这样可以避免让业务层到处出现 plugin.Symbol 类型断言。

package loader

import (
    "context"
    "fmt"
    "plugin"
)

type Runner interface {
    Run(context.Context, []byte) ([]byte, error)
}

func loadOptional(path string) (Runner, error) {
    // 空路径表示使用进程内实现，避免无意义地调用 plugin.Open。
    if path == "" {
        return builtinRunner{}, nil
    }

    p, err := plugin.Open(path)
    if err != nil {
        // 可选插件失败时返回内置实现，并保留原错误供日志和指标记录。
        return builtinRunner{}, fmt.Errorf("插件不可用，已切换内置实现: %w", err)
    }

    symbol, err := p.Lookup("NewRunner")
    if err != nil {
        // 找不到导出符号不是平台问题，不能伪装成成功加载。
        return nil, fmt.Errorf("查找 NewRunner: %w", err)
    }
    factory, ok := symbol.(func() Runner)
    if !ok {
        // 类型不一致通常意味着 contract 或构建环境不一致，应明确失败。
        return nil, fmt.Errorf("NewRunner 类型不兼容")
    }
    return factory(), nil
}

type builtinRunner struct{}

func (builtinRunner) Run(context.Context, []byte) ([]byte, error) {
    // 内置实现只演示兼容后端，真实项目应放入确定的业务逻辑。
    return []byte("builtin"), nil
}

这里有一个容易忽略的边界：plugin.Open 失败时可以降级，并不表示 Lookup 失败也应该降级。缺少符号或类型不匹配往往意味着插件包已经损坏、接口版本错位或部署内容不完整，继续运行可能产生更难排查的结果。

在构建和运行两层处理降级

如果产品明确需要支持 Windows、纯静态构建或关闭 CGO 的环境，最好在构建层就选择实现。动态加载文件只在支持平台且启用 CGO 时参与编译，其他平台提供同名函数返回内置实现。这样不会让业务包散落一堆平台判断，也能让交叉编译更早暴露问题。

//go:build (linux || darwin || freebsd) && cgo

package loader

func openBackend(path string) (Runner, error) {
    // 支持平台才进入真正的 plugin.Open 路径。
    return loadOptional(path)
}

//go:build (!linux && !darwin && !freebsd) || !cgo

package loader

func openBackend(string) (Runner, error) {
    // 不支持平台直接使用内置实现，避免把不可用能力当成运行时重试。
    return builtinRunner{}, nil
}

示例中的两个文件应拆开保存，因为每个 Go 源文件只能有一个包声明和一组构建约束。运行时仍要保留错误处理：即使构建条件满足，插件路径不存在、依赖版本不一致或符号类型不匹配，仍然可能导致打开失败。

把可选插件和核心插件分开配置

真正上线时，建议给加载策略一个明确的配置值，而不是任何错误都自动 fallback：

最后再检查四项：目标平台是否在支持范围内、构建时 CGO 是否符合预期、插件与主程序是否由同一套工具链构建、fallback 是否会改变业务结果。若动态加载只是为了扩展第三方能力，官方也建议评估 RPC、进程间通信或静态编译方案；它们牺牲一部分调用性能，却通常更容易部署和隔离风险。

常见问题

Windows 上能不能只靠捕获错误继续用 plugin.Open？

可以捕获错误，但不能让 Windows 继续执行动态插件路径。应在构建约束或加载器层切换内置实现，业务层继续使用同一个接口。

Linux 上为什么也会打开失败？

支持平台只是前提，插件文件路径、导出符号、工具链版本、构建标签和公共依赖不一致都可能导致失败。此类错误应先判断插件是否可选，再决定是否降级。

fallback 是否应该静默进行？

不应该。至少记录结构化日志、指标或启动提示；对核心业务则直接失败，避免用户在不知情的情况下得到另一套结果。