死代码指永远无法执行或计算结果永不被使用的代码，如未调用函数、赋值后未读取的变量、if(false)内语句；编译器通过静态分析（控制流图、活跃变量分析等）在不运行程序前提下识别其不可达性或非活跃性，并在优化级别（如-O2）下实施死代码消除（DCE）。
什么是死代码，以及编译器怎么识别它
死代码不是“程序卡死”，而是指**永远无法执行到、或计算结果永不被使用的代码**。比如一个从未被调用的函数、一个赋值后就再没读取的局部变量、或者 if (false) 分支里的语句。编译器做死代码消除（DCE），本质是静态分析：在不运行程序的前提下，判断某段代码是否可达、某变量是否活跃、某函数是否可能被引用。
关键点在于：C++ 标准不规定必须做 DCE，它是编译器的优化行为，依赖于优化级别和上下文。你写 int x = 42; 紧接着就 return，x 就大概率被删；但若 x 是 volatile、或地址被取过、或在调试构建中，它就可能保留。
如何触发 GCC/Clang 的 DCE 自动优化
手动实现完整 DCE 算法（控制流图 + 活跃变量分析 + 过程间分析）远超单个开发者能力范围，也不该重复造轮子。正确做法是让编译器替你做——前提是提供足够清晰的信号：
- 使用
-O2或-O3编译，-O1对部分死代码（如无副作用的纯计算）也生效，但保守些 - 避免干扰信号：不要对变量加
volatile，除非真需要禁用优化；不要用__attribute__((used))强制保留无用符号 - 确保函数没有外部链接泄露：把只在本文件用的函数声明为
static或放在匿名命名空间，否则链接器可能不敢删它 - 慎用
std::cout << ...等 I/O：它们有副作用，编译器不会删掉看似“无用”的输出语句，哪怕你没看到打印
示例：
void unused_func() { int x = 1 + 2; } // 不会被调用 → -O2 下整个函数体被删
int main() {
int y = 3 * 4;
return 0; // y 未被读取 → y 的计算和存储通常被删
}
为什么有些“明显死代码”没被删掉
常见误判场景不是算法缺陷，而是你忽略了隐含约束：
立即学习“C++免费学习笔记（深入）”；
-
constexpr函数体内的死代码仍可能被展开：编译器先求值再删，但若 constexpr 计算触发了static_assert或模板实例化副作用，删不掉 - 内联函数中的死分支：如果函数被内联进多个调用点，某一分支在某个调用中“死”，但在另一个中“活”，则整个分支保留
- 异常处理影响可达性：
try { ... } catch (...) { }中的catch块即使从不抛异常，也可能因 C++ 异常模型要求而保留（尤其启用-fexceptions时） - 调试信息干扰：用
-g编译时，某些编译器（如旧版 GCC）会降低 DCE 激进程度，避免调试时变量突然“消失”
想验证 DCE 是否生效，看什么最可靠
别信源码注释或 IDE 高亮，直接看生成的汇编：
- 用
g++ -O2 -S file.cpp生成file.s，搜索对应函数名或变量名，看是否还存在指令 - 更直观：用
objdump -d a.out | c++filt反汇编可执行文件，确认目标函数符号是否还在符号表里（nm a.out | grep your_func） - 注意：LTO（
-flto）会推迟 DCE 到链接时，此时单个 .o 文件里还能看到“死代码”，但最终可执行文件里没了
真正容易被忽略的是：DCE 和链接时优化（LTO）、模板实例化、弱符号、weak vtables 等机制深度耦合。一个看似孤立的死函数，可能因为虚函数表布局需要而被迫保留——这时候删它反而破坏 ABI 兼容性。
