应避免菱形继承，因其引发二义性、数据冗余、构造/析构顺序混乱、内存开销及维护成本激增；推荐用组合替代多重身份建模。
除非你明确需要多继承且已充分评估虚继承带来的开销与复杂度，否则应始终避免菱形继承。它不是“能用就行”的特性，而是设计信号——说明类职责可能已越界。
出现二义性编译错误时必须重构
当你在调用 _name、print() 或任何基类成员时被编译器报错 reference to '_name' is ambiguous，这不是语法问题，而是结构缺陷的直接反馈。此时强行加作用域限定（如 a.Student::_name）只是掩盖问题，无法解决数据冗余。
- 重复修改同一逻辑实体（如身份证号）却影响不到另一份副本，运行期行为不可预测
- 后续新增成员变量或函数会放大维护成本，而非线性增长
- 调试时观察内存布局会看到两份
Person子对象，这是冗余的铁证
涉及构造/析构顺序敏感逻辑时禁用
虚继承改变基类初始化时机：最顶层虚基类（如 Person）由**最派生类**（如 Assistant）直接构造，中间类（Student、Teacher）不再负责其构造。这意味着：
- 若
Student的构造函数依赖Person的某个初始化状态，该假设在虚继承下不成立 - 析构顺序也反转——虚基类最后析构，可能引发资源释放时序错误
- 虚基表指针（vbase pointer）引入额外内存间接层，对嵌入式或性能关键路径是隐性负担
团队协作或长期维护项目中默认禁用
菱形继承要求所有协作者理解虚继承语义、MRO（实际是C++的虚基类初始化规则）、以及内存布局变化。现实中：
- 新人阅读
class Assistant : public Student, public Teacher时，默认按非虚继承理解，极易误改中间类的继承声明 - 代码审查难以覆盖虚基类初始化细节，一个遗漏的
virtual就让整个结构退化为普通菱形继承 - 接口变更（如给
Person新增带参构造）需同步修改所有虚继承路径，而组合方式只需改一处
真正难处理的从来不是语法怎么写，而是当 Assistant 同时要承担学生、教师、管理员三重身份时，你是否还在用继承强行建模——这时候该想的是拆成 StudentRole、TeacherRole 成员对象，而不是再加一层虚继承。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
