一、虚函数与插件系统：动态库中的虚函数

插件系统，说白了就是「运行时加载代码」。你写一个主程序，用户或者第三方开发者可以写一个 .so 或 .dll 文件，丢进去就能扩展功能。这背后靠的就是虚函数。

我最早接触插件系统是在做一个图像处理框架的时候。主程序定义了一组虚函数接口，比如 processImage()、getFilterName()，然后每个滤镜插件去实现这些虚函数。主程序通过 dlopen() 加载动态库，拿到对象指针，调用虚函数——一切看起来都很美好。

但问题很快就来了。

1.1 动态库中的虚函数表

每个类如果有虚函数，编译器就会给它生成一张虚函数表（vtable）。这张表里存的是函数指针。对象的前 8 个字节（64位系统）指向这张表。

当你在动态库里定义了一个类：

// plugin.h
class IPlugin {
public:
    virtual ~IPlugin() = default;
    virtual void execute() = 0;
};

// plugin.cpp
class MyPlugin : public IPlugin {
public:
    void execute() override {
        // 具体实现
    }
};

extern "C" IPlugin* createPlugin() {
    return new MyPlugin();
}

主程序这样加载：

void* handle = dlopen("./libplugin.so", RTLD_LAZY);
auto* factory = (IPlugin*(*)())dlsym(handle, "createPlugin");
IPlugin* plugin = factory();
plugin->execute();  // 虚函数调用

这里有个关键点：plugin->execute() 实际上是通过 vtable 跳转的。主程序只知道 IPlugin 的布局，但实际执行的是 MyPlugin::execute()。只要 vtable 的布局一致，调用就没问题。

二、跨模块的虚函数调用

跨模块调用，说白了就是主程序里 new 了一个对象，但实现在动态库里；或者反过来，动态库里 new 了对象，传给主程序用。

这里有个坑：内存分配和释放必须在同一个模块内。我见过一个项目，主程序用 new 分配内存，动态库用 delete 释放，结果堆崩溃了。为什么？因为不同模块可能用了不同的堆管理器。

解决方案很简单：

• 要么统一用工厂函数创建和销毁对象
• 要么用智能指针 + 自定义删除器

// 正确的做法
extern "C" IPlugin* createPlugin();
extern "C" void destroyPlugin(IPlugin* p);

// 或者用 shared_ptr 的别名构造函数
std::shared_ptr<IPlugin> plugin(factory(), [](IPlugin* p) {
    // 调用动态库里的销毁函数
    destroyPlugin(p);
});

另一个问题是异常。C++ 异常跨模块边界传播，在不同编译器或不同版本下可能崩溃。我建议插件接口里不要抛异常，用错误码或者 std::expected 代替。

三、ABI 兼容性问题

ABI（Application Binary Interface）决定了二进制层面的兼容性。说白了就是：你编译出来的 .so 文件，能不能被另一个编译器编译出来的主程序正确调用。

影响 ABI 的因素很多：

因素	说明	风险等级
编译器版本	GCC 4.x vs GCC 9.x 的 vtable 布局可能不同	高
标准库版本	libstdc++ 的 ABI 在 GCC 5 之后有重大变化	高
编译选项	-fvisibility=hidden 会影响符号导出	中
类布局	虚函数顺序、成员变量顺序必须一致	高
对齐方式	不同平台的对齐规则可能不同	中

我踩过最深的坑是 GCC 4.8 和 GCC 7 混用。GCC 5 之后引入了新的 ABI，std::string 的布局变了。主程序用新 ABI，动态库用旧 ABI，传一个 std::string 过去，直接内存越界。

四、插件接口设计

好的插件接口设计，应该遵循几个原则：

4.1 接口要稳定

一旦发布，接口就不能随便改。我习惯用纯虚类作为接口，不包含任何成员变量。这样 vtable 的布局只受虚函数影响，不受数据成员影响。

class IPlugin {
public:
    virtual ~IPlugin() = default;
    
    // 版本信息
    virtual uint32_t getVersion() const = 0;
    
    // 核心功能
    virtual bool initialize(const Config& cfg) = 0;
    virtual void shutdown() = 0;
    virtual Result process(const Input& in, Output& out) = 0;
    
    // 查询能力
    virtual const char* getName() const = 0;
    virtual uint32_t getCapabilities() const = 0;
};

4.2 用版本号管理

接口变化是难免的。我建议每个插件都暴露一个版本号，主程序在加载时检查兼容性。

extern "C" {
    uint32_t getPluginVersion() { return 2; }
    const char* getPluginName() { return "MyFilter"; }
    IPlugin* createPlugin() { return new MyPlugin(); }
    void destroyPlugin(IPlugin* p) { delete p; }
}

4.3 避免虚函数过多

虚函数调用本身有开销，但更关键的是：虚函数越多，vtable 越大，跨模块调用的风险越高。我一般把接口控制在 5-10 个虚函数以内。

4.4 用结构体传参

如果接口参数很多，用结构体传参比一个个传要好。这样增加参数时不需要改虚函数签名，只需要在结构体里加字段。

struct PluginConfig {
    uint32_t version;       // 结构体版本
    const char* dataPath;
    uint32_t bufferSize;
    bool enableLogging;
    // 后续可以加字段，不影响已有接口
};

五、知识体系总览

下面这张图把虚函数与插件系统的核心逻辑串起来了：

嗯，这张图把整个流程串起来了。主程序通过动态加载拿到插件对象，通过虚函数表跳转到实际实现，中间最关键的就是 ABI 兼容性。你想想看，如果主程序和动态库对 vtable 的理解不一致，那调用就全乱套了。

我个人习惯在插件 SDK 里放一个 abi_check() 函数，运行时校验编译选项和标准库版本。虽然不能完全避免问题，但至少能提前报错，而不是莫名其妙地崩溃。

---

公众号:蓝海资料掘金营，微信deep3321