c++oding="utf-8" ?>
C++插件化架构需手动切断编译依赖、严守ABI边界、管理生命周期：共用头文件，仅通过extern "C"函数交互，禁用跨模块new/delete与dynamic_cast；导出函数须正确关闭名字修饰并设置可见性，销毁必须由插件自身提供配对函数，dlclose前务必先调用destroy_instance。
插件化架构在 C++ 里不是靠框架“自动实现”的，而是靠你主动切断编译期依赖、守住 ABI 边界、手动管理生命周期。只要主程序和插件共用一份头文件、只通过 extern "C" 函数交互、不跨 so/dll 调用 new/delete 或 dynamic_cast，就能跑起来——哪怕只有三行代码。
怎么导出工厂函数才不会被 dlsym/GetProcAddress 找不到
符号找不到是最常见的卡点，根本原因就两个：名字修饰没关、可见性没开。
-
extern "C"必须包裹整个函数声明块，不能只加在函数前——否则 Windows 下__declspec(dllexport)和 Linux 下visibility("default")都会失效 - Linux 编译插件时必须加
-fvisibility=hidden，再用PLUGIN_API显式标记导出函数；否则所有非static符号都进动态表，容易冲突 - Windows 下漏掉
__declspec(dllexport)，或头文件没被插件源文件包含，dumpbin /exports plugin.dll就看不到函数名 - 验证方式固定：
nm -D libplugin.so（Linux）或dumpbin /exports plugin.dll（Windows），输出里必须有未修饰的函数名，比如create_plugin_instance，而不是_Z22create_plugin_instancev
为什么不能直接 new 插件对象然后传指针给主程序
因为 new 和 delete 的实现归属不同模块。主程序用 libc++ 的 operator new 分配内存，插件用 libstdc++ 的 operator delete 释放，大概率崩溃。
- 插件必须自己提供
create_instance()和destroy_instance(void*)一对函数，且两者必须用同一套内存管理逻辑 - 主程序拿到指针后只能调用插件导出的销毁函数，绝不能写
delete ptr或free(ptr) - 如果插件内部用了 STL 容器（如
std::vector），容器内存也必须由插件自己分配/释放，不能把容器对象直接跨边界传递
纯虚类接口 vs C 函数指针：选哪个更稳
纯虚类看着更“C++”，但实际落地时限制极多；C 函数指针看似原始，反而最扛折腾。
- 纯虚类要求主程序和插件用完全相同的编译器、标准库、RTTI 开关、异常模型、甚至
-fPIC选项，否则dynamic_cast失败、虚表偏移错乱、析构不执行 - C 函数指针只依赖调用约定（
__cdecl或__stdcall），跨 GCC/Clang/MSVC 都能通，还能被 Python、Rust 等语言直接调用 - 折中方案是：用纯虚类定义业务逻辑接口（如
IRenderer），但工厂函数仍走extern "C"，即extern "C" IRenderer* create_renderer();—— 接口类型安全由 C++ 保证，ABI 安全由 C 函数兜底
dlclose 后还能不能继续用插件对象
不能。一旦 dlclose()（Linux）或 FreeLibrary()（Windows）返回成功，插件代码段已从进程地址空间卸载，任何对其函数或静态数据的访问都是未定义行为。
- 常见错误：先
dlclose()，再调用destroy_instance()—— 此时函数地址已失效，直接 crash - 正确顺序永远是：
destroy_instance(ptr)→dlclose(handle) - 如果插件内部开了线程、注册了信号处理、或持有外部回调（如 Qt 的
QObject::connect），dlclose不会自动清理这些状态；得在destroy_instance里手动 stop 线程、disconnect、unregister - 生产环境建议：禁用卸载，只做“逻辑禁用”（跳过调用）+ 进程重启；热加载的稳定性代价远高于便利性
真正难的从来不是写几行 dlopen，而是让每个插件开发者都记住：不能跨边界传 std::string、不能在插件里 throw 异常给主程序捕获、不能假设全局变量地址一致——这些约束不写进文档，光靠编译器拦不住。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
