virtual + override 是底线要求，因LSP要求“替换后行为不变”；若父类未声明virtual而子类用new隐藏，则父类引用调用时仍执行父类逻辑，违背LSP透明性前提。
子类重写方法时，为什么 virtual + override 是底线要求？
因为 LSP 的核心是“替换后行为不变”——如果父类方法没声明为 virtual，子类用 new 隐藏它，那通过父类引用调用时，实际执行的仍是父类逻辑，根本不是子类对象在“替换”，而是被悄悄绕开了。这直接违反 LSP 的透明性前提。
- ✅ 正确：父类用
virtual void Work()，子类用override void Work()，Animal a = new Cat(); a.Work()真正调用Cat.Work() - ❌ 危险：父类是普通
void Work()，子类用new void Work()，同样代码会调用Animal.Work()，子类行为完全不可见 - ⚠️ 注意：
override不能改返回类型、不能扩大访问修饰符（比如父类protected，子类不能public override），否则编译报错，本质就是在强制守 LSP 的契约边界
构造函数链中，base() 调用不当怎么偷偷破坏 LSP？
父类构造函数常承担状态初始化（如校验必填字段、设置默认值）。若子类构造函数没显式调用合适的 base(...)，而依赖默认无参构造，可能导致父类关键字段未初始化或被设为非法值——这时子类对象虽然能创建，但一调用继承来的方法就抛异常，等同于“我爸会开车，我坐上驾驶座却打不着火”。
- 父类有带参构造且没提供无参构造 → 子类必须用
: base(x, y)显式传递合法参数 - 若父类构造中做了非空检查（如
if (name == null) throw ...），子类传null就直接崩，这不是多态问题，是构造阶段就违背了“子类应能胜任父类所有使用场景” - 建议：父类构造函数尽量做最小必要初始化；复杂校验可推迟到虚方法中，由子类按需
override实现
属性和字段的继承，哪些地方最容易踩 LSP 的“行为不一致”坑？
字段本身不参与多态，但属性的 get/set 可以被重写。常见陷阱是子类重写 set 时加了新约束（比如只允许正数），但父类契约没声明这个限制——外部代码按父类文档设负数，运行时突然炸，这就是后置条件弱化（LSP 明确禁止）。
- 父类属性
public virtual int Speed { get; set; }意味着“任何 int 都可赋值”，子类override的set就不能 throw 或静默修正值 - 若真需要约束，应在父类就把契约写清楚：比如改为
protected virtual void ValidateSpeed(int value)，子类可重写验证逻辑，但父类set里仍统一调用它 - 私有字段永远继承但不可见，所以别指望子类靠改父类私有字段来“修正行为”——那是黑盒操作，LSP 要求的是公开契约层面的兼容
用 is / as 做类型判断时，为什么反而暴露 LSP 设计缺陷？
真正符合 LSP 的继承体系，应该不需要在运行时反复判断“你到底是哪个子类”。一旦出现 if (obj is Cat) ((Cat)obj).Meow(); else if (obj is Dog) ((Dog)obj).Bark();，说明父类抽象不足，子类行为已脱离统一接口，此时用多态调用 obj.MakeSound() 才是正解。
-
as强转失败返回null，看似安全，但掩盖了“本该通用却硬要分支处理”的设计债 - 如果业务逻辑确实需要区分类型（如日志记录不同子类的专属字段），优先考虑用虚方法或抽象方法暴露差异点，而不是让调用方去拆箱
- 一个信号：当你写完
as还得补if (result != null)，大概率说明父类缺少必要的虚成员来承载这种变化
LSP 不是语法检查器，它藏在每次父类引用调用子类方法的那一刻——只要那个调用结果和父类文档承诺的不一致，哪怕只差一行日志、一个返回码、一次静默截断，就是破约。最隐蔽的破约，往往发生在没人写的测试用例里。
