虚函数调用前后需执行逻辑时NVI惯用法是否应始终采用？

NVI不是面向对象设计的必选银弹，不存在“所有基类都该用NVI”的说法，开发中不需要无差别套用这个模式，它的所有弊端本质都来自于「为了获得对派生类的强管控权，付出的固定成本与灵活性牺牲」，对应你提到的几个疑惑可以逐一拆解：

• 关于“误用NVI导致代码体量增大”的说法，你觉得它能减少重复代码的前提是：所有派生类真的共享完全一致、不需要定制的前置/后置/调用流程逻辑。如果一个基类根本没有这类公共逻辑，硬套NVI等于给每个虚函数平白多写一层非虚包装函数，虚函数数量多的时候这部分无意义的冗余代码会非常多。更糟的误用是为了凑NVI的形式，把本来属于派生类的差异化逻辑硬抽到基类的包装层，最后基类里堆满判断不同派生类的分支逻辑，代码体量会涨得更快，可维护性反而更差。
• 你提到的“把基类虚函数设为protected就能支持派生类调用基类实现”确实是NVI的标准实现方式，但这不是零成本的特性：你需要额外做访问权限的设计约束，团队协作中只要有人图省事把虚函数改成public，NVI的强管控逻辑就直接失效，之前写的包装层等于白做。
• 关于“NVI限制的特殊行为是不是本身设计有缺陷”这个判断是错的，真实开发中确实存在NVI无法优雅支持的合法需求。举个最常见的例子：你做一个日志基类，NVI包装层固定了所有日志输出前要自动加时间戳、打调试埋点，但总有派生类对接第三方采集系统时需要输出完全不带前缀的原始日志，这时候NVI把前置逻辑、调用时机完全焊死在基类，派生类根本绕不开，除非你给基类加一堆破坏封装的特殊开关，否则根本实现不了需求，这类差异化场景不是设计缺陷，是真实存在的业务需求。

什么时候适合用NVI #

只有当你的基类明确满足以下特征时，NVI的收益才会远大于成本：

• 基类持有所有派生类必须遵守、不允许修改的固定逻辑：比如参数合法性校验、调用权限检查、线程锁获取/释放、接口调用埋点、类状态不变式校验，这类逻辑用NVI统一实现在基类，确实能避免派生类重复写、漏写，大幅降低误用概率。
• 接口的执行流程是严格固定的：比如模板方法模式定义的“资源初始化->执行核心操作->资源回收”流程，不允许派生类调整执行顺序，用NVI实现是非常稳妥的选择。

什么时候不要硬套NVI #

遇到以下场景硬上NVI基本只有坏处没有好处：

• 基类是纯接口类，没有任何公共的通用逻辑：比如定义抽象能力的Serializable、Comparable这类纯接口，基类本身没有任何需要统一执行的逻辑，多写一层NVI包装除了增加代码跳转的阅读成本，没有任何实际价值。
• 派生类需要高度自定义执行流程：比如开放给第三方的插件扩展基类，不同插件的执行时机、前后置逻辑差异极大，基类根本抽不出通用的固定流程，这时候用NVI只会把扩展能力堵死。
• 处在性能极端敏感的热点调用路径：虽然大部分情况下非虚包装层的调用会被编译器优化内联，但在每帧要调用几十万甚至上百万次的核心渲染、计算路径上，这一层间接调用如果没被优化掉，就是完全不必要的性能开销。

本质上NVI是一个用灵活性换管控力的设计权衡，它的优势和弊端都是这个核心权衡的直接体现，从来不存在什么“应该始终应用”的设计模式，要不要用完全取决于你当前的场景是不是真的需要基类对派生类的行为做强约束。

内容的提问来源于stack exchange，提问作者Dean Lee