扩展性需精准抽象而非盲目加虚函数，仅对存在运行时行为差异的函数使用virtual，其余优先inline或模板，避免vtable膨胀与ABI风险，并依变化轴合理分层设计。
扩展性不是加虚函数就能自动获得的
很多人一想到“以后要加新类型”，第一反应就是把基类所有函数都改成 virtual，甚至直接写成纯虚函数。这反而让接口变重、调用开销变大、编译依赖变深。真正需要扩展的地方，往往只是某几个行为（比如 render()、serialize()），其余如构造、销毁、基础属性访问根本不需要多态。盲目虚化会带来 vtable 膨胀、内联失效、调试符号混乱等问题，尤其在跨模块 ABI 场景下容易引发符号未定义或偏移错位。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 只对确实存在“运行时行为差异”的函数使用
virtual； - 非虚函数优先用
inline或模板实现，保持零成本抽象； - 若某行为未来可能扩展但当前只有一种实现，先用非虚函数 + 注释说明“此处预留扩展点”，比提前虚化更轻量；
- 避免在接口类中暴露任何数据成员——哪怕只读，也会锁死内存布局，破坏二进制兼容性。
简单性不等于删掉抽象，而是控制抽象粒度
一个只有两个派生类的 Shape 基类，硬套策略模式+工厂+插件加载机制，显然过度设计；但反过来，把所有图形逻辑全塞进一个 draw() 函数里用 switch 分支，又彻底放弃可维护性。关键在于判断“变化轴”：是图形种类在变？还是渲染后端在变？或是配置参数在变？每条轴对应不同抽象层级。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 如果新增类型频率低（
- 如果类型由插件/脚本动态加载，必须用纯虚接口 + 独立命名空间 + 显式版本头文件（如
IPlugin_v2.h）； - 如果只是参数组合爆炸（如抗锯齿开关、采样数、光照模型），优先用结构体传参（
RenderOptions）而非扩接口签名； - 组合优于继承：当“行为变化”和“数据结构变化”不重合时（比如同一种图形要在 OpenGL/Vulkan/Metal 上渲染），用策略模式包装后端，而不是让
Shape继承出三个渲染子类。
最容易被忽略的取舍点：对象生命周期与所有权语义
扩展性常被理解为“能加新类”，但实际工程中最常崩塌的环节是对象怎么传、谁负责释放。比如返回 Shape* 给调用方，看似简单，但一旦插件用 malloc 分配、宿主用 delete 释放，或者双方 CRT 版本不一致，立刻 crash。这时候强行追求“简单”（裸指针交接）反而让扩展变成高危操作。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 跨边界对象传递一律用
std::unique_ptr<T>或值语义，明确所有权转移； - 接口类必须带虚析构（
virtual ~IComponent() = default;），否则delete派生类对象会漏掉子类析构逻辑； - 禁用
shared_ptr作跨模块返回值——引用计数器位置不可控，ABI 不稳定； - 若必须用裸指针（如性能敏感的 inner loop），约定由创建方提供
destroy()配套函数，且文档中标明分配器来源。
