纯虚函数定义接口契约的核心是“只承诺行为，不暴露实现”：强制派生类实现统一接口，禁止实例化抽象类，确保编译期检查履约；接口须含虚析构、禁用数据成员与非虚函数，用值语义或智能指针传递对象，通过独立命名空间隔离版本以保障ABI稳定。
用纯虚函数定义接口契约，而不是具体实现
稳定接口的核心是“只承诺行为，不暴露实现”。一旦接口里出现非虚函数、数据成员或默认实现，后续扩展就会被绑定在特定内存布局或逻辑路径上。比如把 update() 写成带函数体的虚函数，子类就可能绕过它直接调用基类版本，导致状态不一致；而纯虚函数强制每个插件/模块必须提供自己的语义。
常见错误是把配置参数塞进接口函数签名里，例如 render(bool use_antialiasing, int max_samples) —— 这会让每次加一个新渲染选项都得改接口，破坏二进制兼容性。正确做法是把配置抽成独立的 setConfig() 方法，或用结构体传参（如 RenderOptions），接口本身保持窄而稳定。
- 所有接口类必须有虚析构函数：
virtual ~IComponent() = default; - 禁止在接口中定义静态成员、友元、模板成员函数（符号导出不可控）
- 避免返回裸指针或引用：优先用
std::unique_ptr<T>或值语义，防止插件内部资源生命周期失控
接口版本控制必须靠 ABI 级隔离，不能只靠注释或宏
很多团队在接口头文件顶部加一行 // v2.1 就以为完成了版本管理，结果插件加载时崩溃在 dlsym 找不到符号，或者 vtable 偏移错位——因为 C++ 没有运行时接口版本检查机制。
真正可行的方式是为每个大版本创建独立命名空间和头文件，例如 IPlugin_v2.h 和 IPlugin_v3.h，宿主程序通过不同函数名加载对应版本插件：create_plugin_v2() vs create_plugin_v3()。这样即使 v3 接口加了新方法，v2 插件仍能被旧版宿主安全加载。
立即学习“C++免费学习笔记（深入）”；
- Linux 下用
objdump -T libplugin.so | grep create_plugin验证导出符号是否存在 - Windows 下用
dumpbin /exports plugin.dll检查函数名是否匹配 - 禁止用宏开关控制接口字段增删（如
#ifdef PLUGIN_V3），会导致同一头文件在不同编译单元中产生不一致的vtable
跨模块对象传递必须走值语义或智能指针，禁用裸指针交接
当插件返回一个对象给宿主，或宿主传入上下文给插件时，如果用 MyObject* 交接，就等于把内存所有权、释放时机、线程安全责任全扔给了调用方——而双方很可能链接了不同的 CRT 或使用了不同的分配器，delete 会直接 crash。
稳定的做法只有两种：一是用 std::shared_ptr<const IConfig> 明确共享所有权；二是用完全值语义的结构体（POD 或 move-only 类型），例如 struct PluginInfo { std::string name; uint32_t version; };。前者适合长生命周期对象，后者适合一次性的元数据。
- 插件内部 new 出的对象，绝不能让宿主 delete —— 必须提供配套的
destroy_xxx()导出函数 - 避免在接口中暴露
std::vector或std::string成员：它们的内存布局在不同 STL 实现间不保证 ABI 兼容 - 若必须传容器，用
std::span<const uint8_t>或自定义固定大小缓冲区（如char buffer[256]）代替
插件初始化失败必须由接口层捕获，不能让异常跨 DLL 边界
C++ 异常无法安全跨越动态库边界。Windows 上抛出异常到另一个 DLL 可能触发未定义行为；Linux 下即使能 catch，栈展开也可能失败。所以 initialize() 这类关键接口绝不能 throw，必须用返回码明确表达失败原因。
更进一步，宿主程序不该依赖插件的 initialize() 返回值做逻辑分支，而应把它当作“准入检查”：失败就卸载插件，不进入后续流程。否则容易出现部分初始化成功、状态不一致的灰色地带。
- 推荐返回枚举类型：
enum class InitResult { Success, MissingDependency, InvalidConfig }; - 禁止在接口函数中使用
std::exception_ptr或任何标准异常类型作为返回值 - 日志输出必须走宿主提供的
ILogger*回调，插件自身不得直接调用printf或std::cout
int 成员，也会让所有已编译插件失效。 
