夜雨聆风
从"改一处崩全局"到"各自独立互不影响"，这篇拆解插件架构的 3 种方案，和你最该选的那个
一、第 8 次崩溃之后
上一篇说了怎么被 60 万行项目吓到，这一篇讲怎么拆。
改了一个相机参数，视觉检测模块崩了。修好视觉检测，数据报表又挂了。等我把报表修好，QA 走过来问我："昨天的版本还能跑，今天怎么连主窗口都打不开了？"
这种"改一处崩全局"的事，你干过吗？
我干过。不止一次。光 Aether 1.0 阶段，我就经历了至少 8 次这种连锁崩溃。每次都是同一个模式：某个模块改了 3 行代码，5 个不相关的功能同时出事。
不是代码写得烂。是架构从一开始就没想过"怎么让别人改他的代码时不影响到我"。
后来我用插件架构把整个项目重拆了一遍。结果怎么样？
从那以后，再也没有因为一个模块的修改牵连过其他模块。
今天就来拆这 3 种方案。看完你就能判断：你的项目该用哪种，以及为什么 Aether 选的是第 2 种。
二、裸奔 vs 插件：一张表撕开差距
先看一个最简单的场景：你的项目有 3 个模块——相机控制、视觉检测、数据报表。
❌ 典型"裸奔"写法
// monolithic_main.cpp
#include <QApplication>
#include <QMainWindow>
// 相机控制
class CameraWidget : public QWidget { /* 200 行 */ };
// 视觉检测
class VisionWidget : public QWidget { /* 300 行 */ };
// 数据报表
class ReportWidget : public QWidget { /* 250 行 */ };
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QMainWindow window;
// 三个模块都塞在 main 里
window.setCentralWidget(new CameraWidget());
// 改一个就要重新编译整个项目
// 链接 30 分钟，只改了一行代码
return app.exec();
}
问题在哪？所有模块编译成一个 exe，改一行代码就要全量重编。 而且谁都可以调用谁的函数，时间一长就变成一团乱麻。
✅ Aether 的插件写法
// plugins/camera/cameraplugin.cpp
// 相机控制：独立的插件 DLL
bool CameraPlugin::initialize(QString *errorString)
{
// 注册到对象池，其他插件通过接口获取
// 不直接依赖头文件，只依赖接口
m_cameraService = new CameraService();
PluginManager::addObject(m_cameraService);
return true;
}
// plugins/vision/visionplugin.cpp
// 视觉检测：另一个独立 DLL
bool VisionPlugin::extensionsInitialized()
{
// 从对象池拿到相机服务
// 不知道具体实现，只认得接口
auto *cs = PluginManager::getObject<ICameraService>();
if (cs) {
cs->startCapture();
}
return true;
}
这样拆之后，改相机算法，重新编译 camera.dll 就行。vision 和 report 碰都不用碰。
差距不是技术，是组织方式。
但问题来了：插件架构也有很多种。选错了，比不拆还惨。
三、3 种插件架构，我全都试过
方案 1：编译期静态链接
最简单。把功能模块编译成静态库（.lib/.a），链接进主程序。
# ❌ 编译期方案：改一个库就要重链主程序
add_library(camera STATIC camera.cpp)
add_library(vision STATIC vision.cpp)
target_link_libraries(myapp camera vision) # 全部链接进 exe
优点：简单粗暴，性能零损耗，调试最方便。
缺点：改一个模块还是要重新链接主程序。模块之间还是可以互相调用私有函数，因为它们在同一个地址空间、同一个编译单元。
适合：嵌入式系统、对性能极其敏感、模块极少变更的项目。不适合：团队协作、频繁迭代的桌面软件。
方案 2：运行时动态加载（Aether 的选择）
模块编译成独立的 DLL/SO，主程序在运行时通过加载器按需载入。
// ✅ Aether 的方案：运行时加载
// 主程序只用 QPluginLoader，不链接任何业务代码
QPluginLoader loader("plugins/camera.dll");
if (auto *plugin = qobject_cast<IPlugin *>(loader.instance())) {
plugin->initialize(&errorMsg); // 成功！
}
# ✅ 每个插件独立编译，不链接主程序
fz2_setup_plugin(camera
SOURCES cameraplugin.cpp
LINKS extensionsystem # 只依赖框架接口
)
# vision 完全不知道 camera 的存在
fz2_setup_plugin(vision
SOURCES visionplugin.cpp
LINKS extensionsystem
)
优点：改一个插件编一个 DLL，其他不用动。插件间零头文件依赖，彻底解耦。甚至可以在不停机的情况下替换插件（某些场景）。
缺点：多了 DLL/SO 的加载开销（基本可忽略）。要做好接口版本的兼容管理。
Aether 选这条路的理由很简单：工业上位机软件需要频繁迭代，同时又不能影响产线运行。 这是唯一兼顾灵活和安全的选择。
方案 3：混合模式
核心基础设施编译成静态库，业务功能做成动态插件。
# 混合：核心静态 + 业务动态
add_library(core_lib STATIC extensionsystem.cpp container.cpp)
# 框架核心静态链接到主程序
target_link_libraries(myapp core_lib)
# 业务插件动态加载
fz2_setup_plugin(camera LINKS core_lib)
fz2_setup_plugin(vision LINKS core_lib)
优点：核心代码性能最优，业务插件保持灵活。
缺点：架构复杂度最高，要同时管静态链接和动态加载两套机制。
适合：既需要高性能核心、又需要灵活扩展的大型系统，比如 IDE、浏览器。
对比总结
| 高 | |||
| 单模块重编 | |||
| 好 | |||
| 高 | |||
| 桌面应用/团队开发 |
Aether 为什么选方案 2？因为它的核心痛点永远是**"团队迭代效率"**。工业场景下，产线不会等你编译 30 分钟，客户不会容忍改一行就崩另一个功能。
四、Aether 的插件机制：怎么做到"拆得开又合得起"
动态加载只是第一步。真正难的是：怎么让一堆独立的 DLL 有序协作？
4.1 接口先行
每一个插件都继承 IPlugin 接口，框架只认这个接口，不认具体类。
// iplugin.h（简化）
class IPlugin : public QObject
{
Q_OBJECT
public:
// 加载时的初始化（注册服务、创建对象）
virtual bool initialize(QString *errorString)= 0;
// 所有插件初始化完后调用（拿别人的服务）
virtual void extensionsInitialized()= 0;
// 延迟初始化，不影响启动速度
virtual bool delayedInitialize(){ return true; }
// 关闭前清理
virtual ShutdownFlag aboutToShutdown(){ return SynchronousShutdown; }
};
所有插件只要实现这 4 个方法，框架就能统一调度。不需要知道每个插件内部在干什么。
4.2 状态机：每一步都有明确的状态
插件不是一拍脑门就加载的。Aether 定义了 7 个状态，每一步都经过严格校验：
Invalid → Read → Resolved → Loaded → Initialized → Running → Stopped → Deleted
每个状态转换对应一个操作：
// 框架内部的状态管理（简化）
switch (m_state) {
case Invalid:
parsePluginJson(); // 读 plugin.json
m_state = Read; // 解析成功
break;
case Read:
resolveDependencies(); // 检查依赖有没有
m_state = Resolved; // 依赖满足
break;
case Resolved:
loadLibrary(); // QPluginLoader 加载 DLL
m_state = Loaded; // 加载成功
break;
case Loaded:
plugin->initialize(); // 调用初始化
m_state = Initialized; // 初始化成功
break;
}
任何一步失败，状态就卡住，框架不会继续往下走。 这就是"出错了不隐瞒，让你第一时间看见"的设计哲学。
4.3 依赖解析：谁说插件就没人管
插件不是想怎么依赖就怎么依赖的。每个插件带一个 plugin.json，明确声明依赖谁、什么版本。
// plugins/core/plugin.json
{
"Name": "Core",
"Version": "1.0.0",
"Vendor": "Aether",
"Dependencies": []
}
// plugins/mvvm/plugin.json
{
"Name": "Mvvm",
"Version": "1.0.0",
"Dependencies": [
{"Name": "Core", "Version": "1.0.0"}
]
}
// plugins/home/plugin.json
{
"Name": "HomePage",
"Version": "1.0.0",
"Dependencies": [
{"Name": "Core", "Version": "1.0.0"},
{"Name": "Mvvm", "Version": "1.0.0"}
]
}
框架在加载前会做拓扑排序：Core 先加载，再加载 Mvvm，最后加载 HomePage。
加载顺序（按依赖解析）：
① Core ← 无依赖，最先
② Mvvm ← 依赖 Core，其次
③ Container ← 依赖 Core，与 Mvvm 同级
④ HomePage ← 依赖 Core + Mvvm，最后
如果依赖不满足——比如 Mvvm 版本要求 1.0.0 但你装的是 0.9.0——框架直接拒绝加载，不会等到运行时再崩。
五、3 个致命陷阱，我都踩过
插件架构不是银弹。用不好，比单体项目还惨。
陷阱 1：循环依赖
插件 A 依赖插件 B，插件 B 又依赖插件 A。框架启动就死锁。
A ──depends on──→ B
↑ │
└──depends on─────┘ ← 循环！
解决方法：拆出公共接口到一个独立的"接口插件"或者移到框架层。或者用前向声明 + 对象池的方式打破循环。
陷阱 2：接口版本不匹配
你改了 IPlugin 的虚函数表，加了一个纯虚方法。但旧插件编译时还是老接口。运行时一调用，虚表错位，直接踩内存。
// 陷阱：在已发布的接口中插入新方法
class IPlugin {
// 原来只有 initialize
virtual bool initialize(QString*)= 0; // 原第 1 个虚函数
// 第 2 个版本：加了一个方法，没更新大版本号
virtual void newMethod()= 0; // 新第 2 个虚函数
// 旧插件的 extensionsInitialized 还在第 2 个位置
// 调用 newMethod 实际跳到了错误的地址 → crash
};
解决方法：接口一旦发布就只增不减。非要改就升大版本号，旧插件重新编译。Qt 的 Q_DECL_DEPRECATED 宏也是个好帮手。
陷阱 3：DLL Hell
Windows 上最经典的问题。你的程序目录下有 QtCore.dll，系统 PATH 里也有一个旧版本。你加载的插件链接了旧版 Qt，两个版本打架。
表现：启动就崩、中文乱码、new 出来的对象 delete 时炸了。
解决方法：所有 DLL 统一放一个目录，运行时指定路径，禁止搜 PATH。Aether 的做法是启动时强制设置 Qt 库路径：
// 在所有 QPluginLoader 调用之前
QCoreApplication::setLibraryPaths({
QDir::currentPath() + "/plugins", // 只搜自己的目录
QDir::currentPath() + "/bin"// 不碰系统 PATH
});
一句话：别相信系统的 DLL 搜索顺序。自己管好自己的目录。
六、写在最后
回到开头那个问题：改一个参数崩 3 个模块，这是不是你？
如果你的项目已经 10 万行以上，你还把所有代码塞在一个 exe 里，那炸是迟早的事。
插件架构不是炫技，是应对复杂度的唯一出路。Aether 选的是运行时动态加载这条路，不是因为它最潮，而是因为它在灵活和可控之间找到了最平衡的那个点。
💬 评论区聊聊：
你的项目用插件架构吗？踩过什么让你崩溃的坑？评论区说说，我每条都会看。
🔄 觉得有用？
收藏这篇文章，下次重构项目时翻出来看看。也转发给你团队里那个还在往 main.cpp 里塞代码的同事——他需要被拯救。
下一篇预告：
下一篇，进入 Aether 最核心的模块——ExtensionSystem。 插件的加载、解析、状态管理、对象池……整个框架的发动机是怎么工作的？ 这也是我踩过最多坑的地方，下篇全拆给你看。
📚 系列目录（持续更新）：
