插件接口必须用extern "C"导出纯C函数，如create_plugin()、destroy_plugin()等；Linux需RTLD_GLOBAL避免符号冲突；主程序与插件须共用同一标准库或禁用C++对象跨边界传递；路径应使用相对路径拼接；ABI需预留reserved字段保障向后兼容。
插件接口必须用 C 风格导出函数，不能直接导出 C++ 类
Windows 的 LoadLibrary 和 Linux 的 dlopen 只能获取 C 风格符号（无名修饰），C++ 类方法、模板、重载函数无法被跨模块直接调用。必须定义一组纯 C 函数作为“桥接入口”，比如：
-
create_plugin()：返回void*或统一基类指针（需约定 ABI） -
destroy_plugin(void*)：释放资源 -
get_plugin_version()：返回int或const char*
所有插件 DLL/SO 必须用 extern "C" 包裹这些函数，禁用 C++ name mangling。
Linux 下 dlopen 时要传 RTLD_GLOBAL，否则符号冲突会静默失败
如果插件内部又依赖了同名但不同版本的第三方库（如 libjson.so），且主程序也链接了它，dlopen 默认使用 RTLD_LOCAL，会导致插件内符号解析失败——但不报错，只在调用时 crash。正确做法是：
void* handle = dlopen("./plugin.so", RTLD_NOW | RTLD_GLOBAL);RTLD_GLOBAL 把插件的符号注入全局符号表，让后续 dlsym 或其他插件可复用。Windows 的 LoadLibrary 默认行为类似，无需额外配置。
立即学习“C++免费学习笔记（深入）”；
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
插件与主程序必须共享同一份 STL / 运行时内存布局
这是最隐蔽的坑：如果主程序用 libc++.so，插件却链接了 libstdc++.so，哪怕只是传递 std::string 参数，也会因 vtable 偏移或分配器不一致导致段错误。解决方案只有两个：
- 所有模块统一编译器 + 标准库（例如全用 Clang + libc++，且都设
-stdlib=libc++） - 彻底避免跨边界传递 C++ 对象——只传
const char*、int、void*，字符串由插件自己malloc，主程序用free（前提是共用同一堆）
推荐后者，更可控。例如插件提供 const char* plugin_get_name()，主程序不 delete，也不 copy，直接用。
Windows 上 DLL 路径解析依赖 PATH 和当前目录，别硬编码绝对路径
用 LoadLibrary("myplugin.dll") 时，系统按顺序查找：exe 所在目录 → 当前工作目录 → PATH 环境变量路径。若插件放在 ./plugins/ 下，应拼接完整路径：
std::string path = "./plugins/myplugin.dll"; HMODULE h = LoadLibraryA(path.c_str());
注意：LoadLibraryW 要求宽字符路径，且当前目录可能被其他线程修改，所以不要依赖 GetCurrentDirectory 动态拼接；直接写相对路径最稳。Linux 同理，dlopen("./plugins/plugin.so", ...) 比 "plugin.so" 更可靠。
插件化真正的难点不在加载，而在 ABI 稳定性——只要接口函数签名改一个参数，所有旧插件就失效。建议早期就用小版本号控制，比如 struct PluginInterfaceV1，并预留 reserved[16] 字段。
