纯虚函数（= 0）用于强制子类实现、基类无法提供有效默认逻辑的接口；普通虚函数用于基类可提供合理默认行为的场景。本质是设计契约判断，非语法偏好。
virtual 函数要不要加 = 0，本质不是语法选择，而是设计契约的判断：这个函数是否必须由子类提供行为，且基类无法给出任何有意义的默认逻辑。
什么时候必须用纯虚函数（virtual void f() = 0）
当基类完全不具备实现该功能的能力或合理性时，强制派生类接管——这是接口定义，不是可选扩展。
- 基类是概念性抽象，本身不能实例化（如
Shape、Stream、Plugin） - 所有派生类的行为差异极大，基类写默认实现反而会误导或引发错误（比如
area()对于不规则图形无法估算） - 你正在设计插件系统或框架回调点，要求每个接入方都明确提供逻辑（如
onEvent()、serialize()） - 编译期就要阻止用户误用基类对象（避免
new Shape这类无效操作）
典型错误：给 draw() 写了个空实现或只输出 "not implemented"，却没设成纯虚——这会让派生类“忘记重写”也不报错，运行时才崩溃。
什么时候该用普通虚函数（virtual void f()）
当基类能提供一个合理、安全、可被多数派生类复用的默认行为时，就该留个兜底实现。
立即学习“C++免费学习笔记（深入）”；
- 功能有通用逻辑，子类只是微调（如
Animal::move()默认走两步，Dog改成跑，Turtle改成爬） - 某些派生类确实不需要改行为（比如日志类中
log()默认输出到控制台，只有少数需要重定向到文件） - 你想支持“部分定制”，而不是“全部重写”（Template Method 模式依赖这种结构）
- 性能敏感路径上，避免强制派生类重复实现相同逻辑（如空校验、资源预分配等前置动作）
注意：virtual 不等于“一定会被重写”。如果 90% 的子类都沿用基类实现，那它大概率不该是纯虚。
纯虚函数其实可以有定义，但极少需要
语法上允许为 virtual void f() = 0 提供函数体，但只能通过作用域解析显式调用（Base::f()），无法被多态调用。实际项目中几乎不用，除非：
- 你在抽象基类里封装了公共清理逻辑，希望所有派生类析构前都执行（但更推荐在虚析构函数里做）
- 你为调试或测试留了一个“兜底 fallback”，但生产环境仍要求子类覆盖（风险高，易混淆）
绝大多数情况下，写了 = 0 就别再写函数体——否则既破坏接口语义，又增加维护负担。
容易被忽略的关键点
纯虚函数不是“高级版虚函数”，它是设计意图的硬性声明。最常踩的坑是：把本该强制实现的接口写成带空实现的虚函数，结果靠文档或人肉检查来保证子类重写——这在大型协作中必然失效。反过来，把可共享的默认逻辑强行拆成纯虚，会导致大量重复代码和接口膨胀。选哪个，最终看的是“这个行为能否脱离具体子类而存在”，而不是“我喜不喜欢抽象”。
