LTO本质是链接时合并多翻译单元的中间表示（如LLVM Bitcode）再全局优化。需编译和链接均启用-flto，否则无效；可提升跨文件内联与虚函数去虚拟化，但代价是编译慢、内存高、调试难。
链接时优化（LTO）本质是把多个翻译单元的中间表示合并后再优化
普通编译流程中，每个
文件单独编译成目标文件（
），此时编译器只能看到本文件内的代码，跨文件的函数内联、死代码消除、常量传播等全局优化全部失效。LTO 的核心动作是在链接阶段，让链接器（如
或
）不直接处理机器码，而是加载编译器生成的“中间表示”（如 LLVM Bitcode 或 GCC GIMPLE），把这些 IR 合并成一个逻辑上的大模块，再跑一遍完整的优化流水线（包括
或
级别的所有 passes）。
启用 LTO 需要编译和链接两步都加标志，缺一不可
只在编译时加
不会生效；只在链接时加也不会触发优化。必须两端一致：
编译每个源文件时：用
—— 此时生成的
实际包含 Bitcode（GCC）或
（Clang），而非纯机器码
链接时：用
—— 链接器调用 GCC/Clang 后端，读取 Bitcode，合并、优化、最终生成可执行文件
若使用
，需确保所有
都用
编译，否则混合 LTO/non-LTO 目标会导致链接失败或降级为非 LTO 模式
LTO 对内联和虚函数调用有实质性改善
这是最常被验证到的收益点。例如一个定义在
的
函数，被
中的虚函数调用间接调用，传统编译无法内联；而 LTO 合并后能识别该调用链，并在优化中完成内联。同样，如果
中的虚函数调用仅发生在单个派生类实例上（且该类定义在
），LTO 可能将虚调用降级为直接调用（devirtualization）。
但注意：
默认不开启跨 DSO 优化（即不优化动态库之间的调用）。若需对
做 LTO，GCC 需配合
，且主程序链接时也需
，同时避免符号隐藏（
会阻碍跨模块分析）。
C函数速查手册（CHM版）
C函数速查手册（CHM版）
下载
立即学习
“
C++免费学习笔记（深入）
”；
LTO 的代价：编译慢、内存高、调试信息弱
实际项目中容易低估这些副作用：
链接时间可能增加 2–5 倍，尤其在大型项目中，
会变成瓶颈；Clang +
比 GCC +
快得多，推荐搭配使用
内存占用显著上升，10k 行 C++ 项目链接时可能吃掉 2–4 GB 内存；CI 环境若内存不足会 OOM
调试体验下降：LTO 后的二进制中行号映射不准、局部变量丢失、内联展开导致栈帧混乱；建议发布构建用 LTO，开发构建关掉
不是所有优化都稳定：某些版本 GCC 在 LTO 下会错误折叠浮点计算（受
影响更大），若程序依赖严格 IEEE 语义，需测试验证
LTO 真正起效的前提是整个构建链条统一——从预处理、编译、汇编到链接，所有环节都要知道“我们正在做全局优化”。漏掉任意一环，就退回传统模型。这也是为什么它在 CMake 中要用
而不是手动加 flag：后者极易遗漏。
.cpp.oldlld-O2-O3-fltog++ -flto -O2 -c a.cpp b.cpp.o.bcg++ -flto -O2 a.o b.o -o progmake.o-fltoa.cppinlineb.cppb.cppa.cpp-flto.so-fPIC -flto -shared-flto-fvisibility=hiddenldlldld.bfdgdb-ffast-mathg++ -flto -O3 -march=native -DNDEBUG main.cpp util.cpp -o app
# 注意：-march=native 和 -DNDEBUG 应在编译和链接时都出现，否则 LTO 可能忽略部分架构特化set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)