必须编译和链接两个阶段都加 -flto 才真正生效，仅编译加则链接退化为普通模式；CMake 需设 INTERPROCEDURAL_OPTIMIZATION ON；静态库须用 gcc-ar 打包，否则 LTO 失效。
gcc/clang 里怎么加 -flto 才真正生效
不加 -flto 编译选项，LTO 就不会启动；但只在编译阶段加 -flto，链接时没配对，照样白搭。必须编译和链接两个阶段都带 -flto，否则中间生成的是普通目标文件，链接器根本看不到 LTO 信息。
常见错误现象：ld: error: lto1: not found 或静默退化为普通链接 —— 这通常是因为只在 g++ -c 时加了 -flto，但最后 g++ main.o util.o -o app 没带 -flto。
- 编译每个 .cpp：用
g++ -flto -O2 -c foo.cpp -o foo.o - 链接最终可执行文件：必须用
g++ -flto -O2 foo.o bar.o -o app（不能漏掉-flto） - 如果用 CMake，得同时设
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)，它会自动在 compile + link 阶段插-flto - Clang 下行为一致，但注意
lld链接器需 ≥ v9，老系统默认ld.bfd可能不支持全功能 LTO
为什么 -flto=auto 和 -flto=4 差很多
LTO 不是开或关的二值开关，它控制跨模块优化的深度和并行粒度。-flto 默认等价于 -flto=1，只做基础函数内联和死代码消除；而 -flto=4 启用多线程、更激进的跨 TU 全局优化（比如虚函数调用去虚拟化、跨文件常量传播），但代价是内存暴涨、链接变慢。
使用场景：调试构建别用 -flto=4；CI 流水线或发布包可上 -flto=3 平衡效果与资源；嵌入式或 CI 内存受限环境，-flto=1 更稳。
立即学习“C++免费学习笔记（深入）”；
-
-flto=thin是 Clang 特有模式，内存友好，适合大型项目，但优化强度略低于 full LTO - gcc 12+ 支持
-flto=auto，它会根据 CPU 核数自动选并行度，但实际效果常不如手指定-flto=3 - 开启
-flto后，nm看不到符号，gdb调试信息可能错位 —— 这是正常现象，不是 bug
静态库（.a）和 LTO 一起用的坑
静态库本身不保存 LTO 信息，ar rc libfoo.a foo.o 会把带 LTO 的 .o “压缩”成普通归档，链接时 LTO 失效。必须用 -flto 配合 gcc-ar（或 llvm-ar）重新打包，否则等于没开。
错误现象：链接后二进制体积没变小、性能无提升，readelf -x .gnu.lto_.symtab libfoo.a 返回空 —— 说明归档里没存 LTO 数据。
- 正确打包静态库：
gcc-ar rcs libfoo.a foo.o bar.o（用gcc-ar替代系统ar） - 或者绕过静态库：直接把所有 .o 传给最终链接命令，避免中间归档
- 如果依赖第三方 .a（比如 OpenSSL），它们大概率没开 LTO，会导致整个链接退化为 non-LTO 模式 —— 此时要么自己重编，要么接受局部失效
调试和符号表在 LTO 下怎么保得住
LTO 会重排、内联、删除函数，导致调试体验变差：断点跳转错位、bt 显示不全、变量显示为 <optimized out></optimized>。这不是配置遗漏，而是优化本身的副作用。
关键取舍点：LTO 和完整调试信息本质冲突。想保留可调试性，只能降级优化强度，或分环境处理。
- 开发构建：用
-flto -O0 -g（gcc 12+ 支持，但部分优化仍生效） - 发布构建：加
-g依然必要，LTO 会保留 DWARF 信息，只是结构更扁平；配合objcopy --strip-unneeded拆出 debug 文件 - 不要信 “加
-frecord-gcc-switches就能完美调试”，它只记录编译参数，不解决符号混淆 - gdb 12+ 对 LTO 符号支持更好，但仍有局限；
addr2line -e app 0x12345仍比 IDE 断点可靠
LTO 最容易被忽略的点是：它让链接变成真正的“编译第二阶段”，所以任何依赖链接时符号可见性的机制（比如弱符号覆盖、__attribute__((constructor)) 的执行顺序）都可能因优化改变行为 —— 这类问题在线下很难复现，上线后才冒出来。
