C#中不存在“隐藏类搜索”，因其为静态类型语言，属性访问在编译期绑定，虚属性才触发vtable查找；非虚属性通常被JIT内联，虚属性则有调用开销。
编译器在处理多态属性访问时，**不会进行“隐藏类搜索”**——这个说法本身混淆了 C# 和 JavaScript/V8 的运行机制。C# 是静态类型语言，没有 V8 引擎那种基于隐藏类（hidden class）的属性访问优化路径。
为什么 C# 里不存在“隐藏类搜索”
C# 编译器（csc）和 JIT 在编译/运行时依据的是已知的类型信息和虚方法表（vtable）结构，不是运行时动态推断对象的“形状”。属性访问本身不参与虚分发，除非你显式声明为 virtual 或 abstract 的属性访问器：
-
get/set访问器默认是非虚的，编译器直接内联或生成直接字段访问（对自动实现属性）或跳转到具体实现（对手动属性） - 只有当你写
public virtual int Value { get; set; }，且通过基类引用调用时，JIT 才会查 vtable——但查的是方法槽位，不是“隐藏类” - 所谓“隐藏类”是 JS 引擎为加速
obj.x这种动态属性查找而设计的内部缓存结构，C# 的obj.X在编译期就绑定到确切的get_X()方法符号
真正影响性能的是虚拟属性访问器的 JIT 分发开销
当你真的用了虚属性，比如：
public class Shape { public virtual void Draw() { } }
public class Circle : Shape { public override void Draw() { } }
// ...
Shape s = new Circle();
s.Draw(); // ✅ 运行时查 vtable，有间接调用成本
但注意：上面是方法，不是属性。换成属性：
public class Shape { public virtual int Area { get; set; } }
public class Circle : Shape { public override int Area { get => base.Area * 2; set => base.Area = value / 2; } }
这时每次访问 s.Area（其中 s 是 Shape 类型引用）都会触发 vtable 查找 + 虚调用，且 JIT 无法内联这些访问器——因为无法在编译期确定实际类型。
- 非虚属性访问：通常被 JIT 内联，等价于字段读写
- 虚属性访问：无法内联，每次调用都有函数调用开销 + vtable 查找延迟（虽然极短，但高频下可观）
- 接口属性（如
IFormattable.ToString()）同样走虚分发，开销模型一致
容易被忽略的陷阱：自动属性 + field 关键字不改变虚性
从 C# 14 开始支持在自动属性的 set 中用 field 做验证：
public int Count { get; set { if (value >= 0) field = value; } }
但这只是语法糖，生成的仍是普通（非虚）属性。如果你把它声明为 virtual，那 field 仍按虚语义处理——但此时 field 指向的是派生类中合成的后备字段，不是基类字段。这容易导致逻辑错位，尤其在多层继承中。
- 虚属性的
field不跨层级共享；每个重写版本都操作自己的后备存储 - 没加
virtual却期望多态行为？访问永远绑定到声明类型，不会走到子类重写 - 用
new隐藏属性（而非override）会导致静态绑定，完全绕过 vtable——看似“多态”，实则失效
真正的性能敏感点从来不是“隐藏类搜索”，而是你是否无意中把高频访问的属性设成了 virtual，又是否在循环里反复通过基类引用去读它。这时候看 IL 或 Benchmark 就会发现，虚属性访问比字段慢 3–5 倍，而 JIT 是否能内联才是关键分水岭。
