虚方法调用开销主要来自运行时vtable查找，而接口调用需两层查找故通常更慢；但.NET 6+ JIT可在单实现场景下对二者分别做monomorphic inline和devirtualization优化，消除开销。
虚方法调用在 C# 中的底层开销来源
虚方法调用比普通实例方法慢，核心在于它必须在运行时查虚函数表（vtable）——每个类型维护一张表，记录该类型所有虚方法的实际地址。JIT 编译器无法在编译期绑定目标，必须生成间接跳转指令（如 call dword ptr [eax+0x8]），多一次内存读取和指针解引用。
常见误区是认为“虚”就一定慢很多。实际上，在现代 .NET（.NET 6+）中，JIT 对单实现场景（即某个虚方法只被一个子类重写）会做 **monomorphic inline** 优化：检测到调用点始终命中同一子类型，就直接内联该实现，完全消除虚调用开销。
- 只有多态频繁切换（如集合里混存不同子类对象）且 JIT 无法稳定推测时，才会退回到真实 vtable 查找
-
virtual方法本身不触发任何额外分配或 GC 压力 - 使用
sealed类或sealed override可显式帮助 JIT 做内联判断
接口调用为什么通常比虚方法更慢
接口调用（如 obj.DoSomething()，其中 obj 是接口类型）需要两层查找：先根据对象实际类型定位其对该接口的实现映射表（interface map），再从中取出对应方法地址。这比单层 vtable 查找多一次间接跳转，且 interface map 结构更复杂、缓存局部性更差。
不过 .NET 6+ 引入了 **devirtualization for interfaces**，当 JIT 能确定接口变量背后只有一个具体类型（例如方法参数声明为 IFoo，但所有传入值都是 ConcreteFoo），也会尝试内联。但该优化比虚方法更保守，触发条件更苛刻。
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
- 接口调用在泛型约束下（
T : IFoo）可能被 JIT 优化为直接虚调用，前提是T在调用点可推导为具体类 - 避免将同一对象反复拆箱为不同接口（如先转
IA再转IB），每次转换都可能触发新的接口查找逻辑 - 用
is+ 直接调用比as+ null 检查 + 接口调用略快，因为前者可跳过接口 dispatch
实测差异有多大？什么情况下真该关心
在非热点路径上，虚方法和接口调用的耗时差异基本可以忽略（纳秒级）。只有在 tight loop 里每秒执行百万次以上、且对象类型高度多态时，才可能观测到 10%~30% 的性能落差（以 .NET 7 Release 模式为准）。
- 用
dotnet-trace+PerfView抓Microsoft-Windows-DotNETRuntime/JIT/InlinerDecision事件，确认关键路径是否被内联 - 不要提前把
virtual改成sealed或把接口换成抽象基类——除非 profiler 明确指出它是瓶颈 - 结构体实现接口会触发装箱，此时接口调用开销主要来自堆分配，远超 dispatch 本身；这种场景应优先考虑 ref struct 或泛型约束规避装箱
替代方案不是不用，而是选对时机
真正影响性能的往往不是 dispatch 机制本身，而是它所掩盖的设计问题：比如本该用策略模式却滥用接口继承树，或本可用 Span<T> 零分配处理却依赖接口抽象。
- 高频路径优先用泛型约束（
T : IComparable<T>）而非接口变量，让 JIT 有机会生成专用代码 - 对极敏感场景（如游戏引擎组件更新循环），可考虑用
delegate缓存或Func<T, R>字段预存调用目标——但要权衡委托分配和缓存失效成本 - 别为了“避免接口”而把逻辑硬编码进主类；可读性和可测试性受损带来的长期维护成本，远高于纳秒级 dispatch 开销
虚方法和接口调用的性能分水岭不在语法层面，而在 JIT 是否能稳定识别单态性。盯着 IL 指令猜快慢不如看 trace 数据；改语言特性前，先确认你真的站在热路径上。
