-flto 能实现跨文件函数内联，因它将中间表示存入 .o 文件，链接时全局分析；需编译和链接均启用，且不可混用非 lto 目标文件。
为什么 -flto 能让跨 .cpp 文件的函数内联生效
普通编译下，g++ 对每个 .cpp 单独编译成目标文件，函数定义一旦不在当前翻译单元里，编译器就“看不见”，自然没法做内联或跨函数优化。LTO 把中间表示（如 GCC 的 GIMPLE）塞进 .o 文件，链接时才真正合并分析——这时候 foo() 在 a.cpp，调用它的是 b.cpp 里的 bar()，链接器配合 LTO 后端就能全貌扫描，决定是否把 foo() 内联进 bar()。
实操建议：
- 必须全程启用：编译和链接都加
-flto，只在编译加没用；g++ -flto -c a.cpp b.cpp+g++ -flto a.o b.o -o prog - 不能混用非 LTO 目标文件：哪怕一个
.o是普通编译出来的，整个链接就会退化为非 LTO 模式 -
-flto=auto或-flto=n（n 是线程数）比裸-flto更稳，避免链接器因内存不足静默禁用 LTO
-flto 下 inline 关键字还重要吗
重要性下降，但没消失。LTO 让编译器能跨文件做内联决策，它会忽略 inline 建议，按实际调用频次、函数大小、是否含虚调用等重新评估。不过 inline 仍影响符号可见性：没加 inline 的函数定义若出现在头文件里，多个 TU 包含会导致 ODR 违规；而加了 inline 就合法。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 头文件里定义函数但没加
inline，LTO 链接时报multiple definition of 'xxx' - 加了
inline却发现没被内联——LTO 判定该函数太大或有地址被取过（&func），直接放弃内联，这时得看-fopt-info-vec-optimized输出确认
LTO 和 -O3、PCH、模板实例化的相互影响
LTO 不是独立优化层，它依赖前端优化结果。比如 -O3 开启的向量化、循环展开，会产出更利于 LTO 分析的中间代码；反过来，没 -O2 或更高，-flto 几乎不带来收益。
使用场景与坑点：
- PCH（预编译头）和 LTO 可共存，但 PCH 本身不参与 LTO 分析——它只加速编译，LTO 仍然只看到你源码里
#include展开后的实际内容 - 模板实例化：LTO 能跨 TU 合并重复实例（如
std::vector<int></int>在多个文件里实例化），但前提是这些实例化代码最终生成的符号名一致；若用了extern template显式导出/抑制，LTO 会尊重这个约束 - 调试体验变差：
-g和-flto一起用时，行号映射可能错乱，GDB 回溯有时跳到奇怪位置；生产构建可用，开发阶段慎用
验证 LTO 是否真起作用的三个硬指标
别只信编译参数有没有写，要看链接后二进制是否真的变了。最直接的方式是比对符号表和反汇编。
实操建议：
- 查符号数量：
nm prog-lto | wc -lvsnm prog-nolto | wc -l，LTO 后通常少几百个内部函数符号（被内联或删除） - 看关键函数是否消失：
nm prog-lto | grep 'my_hot_function'，如果空了，说明大概率被内联或优化掉了 - 反汇编对比：
objdump -d prog-lto | grep -A5 'call.*my_hot_function'，若找不到 call 指令，而是看到一堆被展开的指令块，就是内联成功了
LTO 的效果高度依赖代码结构：大量虚函数调用、运行时多态、函数指针间接调用，都会让 LTO 的跨模块优化能力大幅缩水。不是加了 -flto 就一定快，得看你的热路径里有多少“编译器在链接前根本不敢动”的东西。
