虚函数能被内联，但仅当编译期可确定具体类型时发生；通过具体对象调用、final修饰或lto全局分析成功去虚化时才可能内联，而基类指针/引用调用通常不内联。
虚函数能被内联吗？取决于调用方式
能，但只在编译期能确定具体类型的场景下发生。虚函数的动态分派本质和内联的静态替换是矛盾的——编译器只有在知道 obj 确实是 Derived 类型（而非仅是 Base*）时，才可能把 obj.func() 替换成函数体。
常见错误现象：看到 virtual 就默认“一定不能内联”，结果在 Derived d; d.func(); 这种直接调用中错过优化机会。
- 通过具体对象（非指针/引用）调用：一定可内联（只要函数体满足内联条件）
- 通过
final类或final函数调用：编译器可排除多态，大概率内联 - 通过
Base&或Base*调用：通常不内联，除非 LTO + 全局分析确认无派生类使用该路径
怎么判断某个虚函数调用是否被内联了？
别猜，看汇编。Clang/GCC 加 -S -O2 生成汇编后搜索调用点：call 指令存在说明没内联；若只剩一堆寄存器操作和跳转，大概率已展开。
使用场景：调试性能瓶颈时，发现热路径里频繁调用虚函数，但 profile 显示函数调用开销高——这时要确认是不是本该内联却没成功。
立即学习“C++免费学习笔记（深入）”；
- 检查是否启用了
-O2或更高优化等级（-O1通常不尝试虚函数内联） - 确保没有
-fno-devirtualize或-fno-early-inlining这类禁用选项 - 用
__attribute__((always_inline))强制内联对虚函数无效，编译器会忽略
为什么加了 inline 关键字也没用？
inline 对虚函数只是建议，且编译器优先尊重虚表机制。它不改变调用约定，也不影响 vtable 布局——真正起作用的是调用上下文是否允许 devirtualization（去虚化）。
参数差异：普通函数加 inline 可能提升内联概率；虚函数加了，除了让定义可放在头文件里，对实际内联决策基本没影响。
- 虚函数定义在头文件中是安全的，但不是为了“促进内联”，而是避免 ODR 违规
- 模板中的虚函数（如 CRTP 模式）可完全绕过虚表，此时内联行为更可控
- 成员函数是否
const、是否noexcept会影响 devirtualization 成功率（编译器更倾向信任这些契约）
Clang 和 GCC 在虚函数内联上的实际差异
Clang 更激进：在 LTO 模式下，即使跨编译单元，只要能证明某个虚调用点实际只涉及一个类型，就可能 devirtualize 并内联；GCC 则更保守，尤其在未启用 -flto=full 时，常保留虚调用。
性能影响明显：同一段代码，Clang + LTO 下可能消除 90% 的虚调用开销，GCC 默认设置下可能一个都没消。
- Clang 14+ 默认开启部分跨 TU devirtualization，GCC 12 仍需显式
-fdevirtualize-at-ltrans - 用
[[gnu::hot]]或[[clang::hot]]标记虚函数，可能提高 Clang 的内联意愿，GCC 基本无视 - 虚函数体过大（比如含循环或异常处理）会直接让编译器放弃内联，和是否虚无关
虚函数内联不是开关，是编译器在类型信息、优化等级、链接策略之间做的权衡。最容易被忽略的是：哪怕写了 final，如果对象是通过基类指针创建的（new Base），依然无法触发内联——关键永远在调用点的静态类型，不在声明端。
