为何virtual关键字作用于方法而非类？相关设计考量咨询

你提到的从编译器和语义直观性出发的思路有道理，但语言设计者还会考虑以下几个实际因素：

• 传统范式的兼容性：多数经典面向对象语言（比如C++、Java）都遵循“virtual仅标记方法可重写，类是否抽象由单独的abstract关键字控制”的范式。如果打破这个惯例，会大幅提升已有开发者的学习曲线，也会让从旧语言迁移的代码需要大量修改，不利于语言的推广和落地。

• 支持模板方法等设计模式：很多场景下，基类需要提供完整的默认实现，同时允许子类重写其中部分逻辑（比如模板方法模式里的钩子方法）。如果有virtual方法就必须把类设为抽象类，开发者就不得不额外写一个可实例化的子类来封装默认逻辑，凭空增加代码冗余。

• 语义职责的分离：virtual的核心是“方法可被重写”，abstract的核心是“类不可实例化、存在未实现的方法”。把这两个语义拆分开，能让代码的意图更清晰：当你看到一个virtual方法，你知道它可以被重写，但类本身是可用的；当你看到abstract类，你知道它必须被继承才能使用。合并两者会模糊这种关键的语义区分。

• 编译器实现的简洁性：传统编译器中，虚函数表的维护和类的抽象性检查是两个独立的模块。如果强制virtual方法绑定抽象类，需要额外增加编译期的关联检查逻辑，提升了编译器的实现复杂度和维护成本，也会限制后续语言扩展的灵活性（比如添加sealed类时，还要处理其中virtual方法的冲突）。

• 最小惊讶原则：如果一个类的所有方法都有完整实现，只是某个方法允许子类重写，完全没有理由不让这个类被实例化。强制抽象会让开发者为了满足语法要求做无意义的工作，违背了“语言应该符合开发者直觉”的设计原则。

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