根本原因在于编译器按就近匹配规则将else绑定到最近未配对的if，而非依据缩进；必须为所有if/else分支强制使用花括号以消除歧义。
根本原因在于：编译器不认缩进，只按语法规则把 else 绑定到它前面最近一个尚未配对的 if 上。没有花括号时，这种“就近匹配”会完全违背人的直觉和视觉排版，导致逻辑跑偏。
编译器眼里根本没有缩进
你写的代码可能是这样：
if (a) if (b) printf("ok"); else printf("fail");
人眼看着 else 和第一个 if (a) 对齐，自然认为它属于外层判断。但编译器从 else 往前扫描，最先遇到的是 if (b)——它还没被别的 else 占用，于是立刻配对。结果是：printf("fail") 实际上是 if (b) 的 else 分支，不是 if (a) 的。
单条语句自动成块，放大嵌套歧义
C/C++/Java 等语言允许 if 后面不写花括号，但规则很严格：只把紧随其后一条完整语句当作该 if 的分支。这意味着：
-
if (x) if (y) a();→ a() 只在 x 和 y 都为真 时执行 -
if (x) if (y) a(); else b();→ else b() 属于 if (y)，if (x) 根本没有 else - 一旦 x 为假，整个内层 if (y) ... else ... 都不会运行，b() 永远不执行
你以为的“暂时只有一行”，其实是定时炸弹
今天写 if (valid) log("ok");，看起来干净利落。明天加个调试语句变成：
if (valid)
log("ok");
update_status();
没加花括号的话，update_status() 就彻底脱离 if 控制，无论 valid 是真是假都会执行。这种错误往往上线后才暴露，排查起来非常隐蔽。
唯一可靠解法：把花括号当标点用
不是“可加可不加”的风格选择，而是防止歧义的语法刚需：
- 所有 if、else if、else 后面，一律加
{ }，哪怕里面只有一条语句 - 把
if (cond) stmt;改成if (cond) { stmt; } - 用编辑器配置保存时自动补全大括号，或启用 clang-tidy / Checkstyle 等工具对裸 if/else 发出警告
- 团队规范中明确禁止生产代码出现无花括号的条件分支
