C++插件加载应使用dlopen/dlsym（Linux）或LoadLibrary/GetProcAddress（Windows）实现运行时动态加载，而非硬链接；需用extern "C"导出纯C接口、POD参数、显式符号导出，并通过工厂函数管理插件生命周期，避免C++ ABI不兼容与内存管理错误。
插件怎么加载：用 dlopen + dlsym 而不是硬链接
动态加载插件的核心是运行时解析共享库，C++ 本身不提供跨平台插件机制，Linux 下最直接的方式就是 dlopen 和 dlsym。硬编码链接（-lplugin）会让主程序和插件强耦合，改一个就得重编译整个程序，违背插件“热插拔”本意。
关键点：
-
dlopen的第二个参数推荐用RTLD_LAZY | RTLD_GLOBAL：延迟解析符号，且让插件里的符号对后续加载的其他插件可见（避免重复定义错误） - 插件 SO 文件必须导出 C 风格符号（用
extern "C"），否则dlsym找不到 C++ 名字修饰后的函数名 - 加载失败时
dlopen返回nullptr，别只看dlerror()输出——它可能返回空指针但没清空上一次错误，建议每次调用前先调一次dlerror()清缓冲
插件接口怎么设计：用纯虚类 + 工厂函数，别传 this 指针
主程序和插件共用一套头文件定义接口，但不能让插件直接继承主程序里的类并 new 出来——这会导致析构错乱（主程序用的是自己的 operator delete，插件用的是自己的）。正确做法是插件只实现接口，主程序通过工厂函数获取实例。
示例接口头文件（主程序和插件都包含）：
立即学习“C++免费学习笔记（深入）”；
struct PluginInterface {
virtual void run() = 0;
virtual ~PluginInterface() = default;
};
<p>// 工厂函数原型，插件必须导出这个 C 函数
extern "C" PluginInterface<em> create_plugin();
extern "C" void destroy_plugin(PluginInterface</em> p);
插件里实现时注意：
- 工厂函数返回 new 出来的对象，但销毁必须由插件自己的
destroy_plugin完成，确保 new/delete 匹配 - 不要在工厂函数里捕获异常——
dlsym拿到的是函数指针，C ABI 不传播 C++ 异常，一抛就崩溃 - 接口类里避免非虚析构、成员变量、模板方法——这些会破坏二进制兼容性
插件怎么卸载：dlclose 不等于立即释放内存
dlclose 只是减少引用计数，当所有句柄都关闭后系统才真正卸载 SO。如果插件里开了线程、注册了信号处理、或 malloc 了内存没释放，dlclose 后那些资源还在，下次再 dlopen 同名 SO 可能出错（比如全局变量重复初始化）。
安全卸载的前提：
- 插件自己提供
shutdown()或类似清理函数，并在dlclose前显式调用 - 主程序不保存任何插件内的裸指针（包括
PluginInterface*），所有对象生命周期严格由插件管理 - 避免插件使用静态局部变量——它们的析构时机不可控，且
dlclose后再次dlopen可能触发重复构造
Windows 怎么办：LoadLibrary + GetProcAddress 是等价替代
Linux 的 dlopen 对应 Windows 的 LoadLibrary，dlsym 对应 GetProcAddress。区别在于：
- Windows DLL 导出函数需加
__declspec(dllexport)，或者用 .def 文件；C++ 类仍要用extern "C"导出工厂函数 -
FreeLibrary行为类似dlclose，但 Windows 对已卸载 DLL 中仍在运行的线程更敏感，容易触发访问违例 - 路径处理差异大：
LoadLibrary("plugin.dll")默认从 EXE 目录找，而dlopen("libplugin.so")按LD_LIBRARY_PATH和默认路径搜索；跨平台时建议统一用绝对路径加载
真正麻烦的不是 API 替换，而是插件 ABI 兼容性——不同编译器（MSVC/Clang）、不同 STL 版本、甚至同一编译器不同运行时（/MD vs /MT）都会导致 std::string 传参崩溃。所以生产环境插件接口尽量只用 POD 类型和 C 函数。
