<p>实际执行的是派生类版本，需通过调试器查看this指针的运行时动态类型：VS中展开this显示Derived*，GDB用ptype this或x/gx查vtable，LLDB用expr -o -- this，而非依赖源码声明或Step Into。</p>
在调试器里停在虚函数调用点，怎么看实际执行的是哪个类的版本
直接看调用栈或当前帧的 this 指针类型，比猜函数名靠谱得多。GDB、LLDB 和 Visual Studio 都能显示运行时 this 的真实动态类型，这才是虚函数分发的依据。
常见错误是盯着源码里写的函数声明（比如 Base::foo()）以为它真在执行基类实现——其实编译器生成的调用指令早通过 vtable 跳转了，源码行号只是“调用发起位置”，不是“执行位置”。
- VS 中断后，在“局部变量”窗口展开
this，会明确显示类似Derived *的类型；右键“转到定义”会跳到Derived::foo的实现（如果符号完整） - GDB 下用
print *this或ptype this，输出中带class Derived就说明实际对象是派生类实例 - LLDB 用
expr -o -- this，会打印带具体类型的对象结构
为什么单步进入（Step Into）有时跳不到预期的派生类函数
因为编译器可能做了内联优化，或者虚函数调用被 devirtualized（去虚化）——这时调试器看到的是内联后的代码，甚至直接是汇编逻辑，不再有清晰的函数边界。
典型表现：明明 this 是 Derived*，但 Step Into 却进了 Base::foo 的汇编块，或直接跳过函数体。
立即学习“C++免费学习笔记（深入）”；
- 确认是否开了优化：GCC/Clang 加
-O0，MSVC 用/Od，否则调试信息不完整 - 强制阻止内联：在虚函数声明前加
__attribute__((noinline))（GCC/Clang）或__declspec(noinline)（MSVC） - 不用 Step Into，改用 Step Over 到下一行，再看
this和寄存器（如rax在 x86-64 上常存 vtable 指针）验证跳转目标
用 GDB 查 vtable 指针和函数地址最直白的方法
虚函数调用本质就是取 this 所指对象头里的 vtable 指针，再按偏移查函数地址。GDB 可以手动读出来，比依赖 IDE 更可控。
假设 foo() 是类第一个虚函数，this 地址是 0x7fffffffe010：
gdb$ x/gx 0x7fffffffe010 # 读对象首地址 → 得到 vtable 指针，比如 0x5555555592a0 gdb$ x/gx 0x5555555592a0 # 读 vtable 首项 → 得到 foo() 实际地址，比如 0x555555558c3a gdb$ info symbol 0x555555558c3a # 查这个地址对应哪函数 → 显示 Derived::foo(void)
注意：vtable 偏移取决于虚函数声明顺序，foo() 是第几个就用第几个地址（从 0 开始数）。
VS 调试时“仅我的代码”干扰虚函数识别怎么办
默认开启“仅我的代码”会让调试器跳过 vtable 查找等底层步骤，导致看起来像直接进了基类函数，其实只是没显示中间跳转。
- 菜单栏 → “调试” → “选项” → 取消勾选“仅我的代码”
- 同时勾选“启用 .NET Framework 源代码步进”（即使写 C++，这选项有时影响原生调试行为）
- 若仍不理想，在调用虚函数前加
__debugbreak()（Windows）或raise(SIGTRAP)（Linux），强制中断在调用点，再手动查this
虚函数的实际落地永远取决于 this 的运行时类型，而不是声明类型或调用位置——所有工具链最终都是在帮你确认这一点。别信代码上写的函数名，信内存里 this 指向的那个对象。
