最直接原因是条件表达式求值为假，需用info registers查看相关寄存器（如rax/rdi）、p/x验证值，并结合p手动求值表达式，同时排查优化干扰、变量未初始化或else绑定歧义。
用 info registers 看条件表达式涉及的寄存器值
if 分支没进去，最直接的原因是条件表达式求值为假。但你不能只信源码里写的 x > 5，得确认它在 CPU 执行那一刻到底算出来啥。GDB 不会自动告诉你“为什么条件不成立”，得自己查参与计算的变量或寄存器状态。
常见错误现象：代码里写的是 if (ptr != nullptr)，但程序跳过了；实际可能是 ptr 已被释放、野指针、或初始化为 0 但被编译器优化掉。
- 先停在
if行（比如b 42），n或s运行到该行，再用info registers查rax/rdi等是否为 0（x86-64 下常用于返回值/参数） - 用
p/x $rax看十六进制值，比p $rax更容易识别空指针（0x0）或非法地址（如0xdeadbeef） - 如果条件含数组下标（如
if (arr[i] == 10)），先p i和p &arr[i]，确认i没越界、地址可访问
用 print 在断点处手动求值条件表达式
GDB 的 p 命令能直接复现 if 判断逻辑，比靠猜可靠得多。注意它和运行时行为一致——比如未初始化变量、优化导致的值丢失，p 也会反映出来。
使用场景：条件里有函数调用（if (validate(x))）、宏展开（if (IS_VALID(y))）或复杂位运算，光看源码看不出真假。
- 在 if 行设断点后，执行
p x > 5—— 如果输出$1 = 0，说明条件为假，分支自然不进 - 对宏，先
macro expand IS_VALID(y)（需带-g3编译），再p展开后的表达式 - 若
p x > 5报错No symbol "x" in current context，说明变量被优化掉了；此时要重新编译：gcc -O0 -g
检查编译器是否把 if 优化成跳转或删掉了
Release 模式下，GCC/Clang 可能彻底移除恒假分支，或把 if (x==5) 替换成无条件跳转。你看到源码有 if，GDB 却根本停不到那行——不是 bug，是优化结果。
性能影响：开启 -O2 后，简单 if 可能消失；但加了 volatile 或调试断点会抑制部分优化。
- 用
layout asm切换到汇编视图，看 if 对应位置是不是只有jmp或直接没了 - 对比
objdump -d ./a.out | grep -A10 "your_func_name"，确认目标指令是否存在 - 临时验证：改用
gcc -O0 -g重新编译，再调试——如果这时能停进 if，基本确定是优化导致
留意 else 的绑定歧义（悬空 else）
你以为没进的是 if 主体，其实程序进了 else——只是这个 else 绑错了 if。C/C++ 语法规定 else 总匹配最近的未配对 if，没有大括号时极易误判。
容易踩的坑：代码缩进误导人，但 GDB 调试时看到的执行流才是真实逻辑。
- 例如：
if (a) if (b) foo(); else bar();—— 这里的else属于内层if (b)，不是外层if (a) - 用
list查看上下文，确认 GDB 实际停在哪条语句（bar()那行？还是foo()那行？） - 永远给 if/else 加大括号，既防逻辑错，也避免调试时反复怀疑执行路径
p 和 layout asm 交叉验证，比反复读源码快得多。
