必须加花括号。这是避免逻辑错位、维护失控和协作踩坑的底线实践，C++中if无花括号仅控制首个分号前语句，后续语句不受影响，易导致行为异常、宏展开错误及dangling else等问题。
要加，强烈建议加。这不是语法强制要求，而是避免逻辑错位、维护失控和协作踩坑的底线实践。
不加大括号时 if 只控制紧邻的一条语句
这是 C++ 语法最常被误读的点：if 后面没花括号时，if 只对它后面**第一个分号前的那条完整语句**生效。后续语句完全脱离 if 控制，无论缩进多整齐。
常见错误现象：
- 代码看着像在 if 里，实际运行时无条件执行
- 加日志、改分支、补 else 时突然行为异常
- 宏定义展开后
exit(1);被当成独立语句执行，else报错“dangling else”
示例：
立即学习“C++免费学习笔记（深入）”；
if (x > 0)
y = 1;
z = 2; // 这行永远执行，和 if 无关！
加大括号后语义清晰且可安全扩展
加了 {} 就明确划定了作用域边界。哪怕现在只有一句，后续加新逻辑、加调试输出、加 else 分支都无需重构结构。
使用场景包括：
- 单行
return、throw或continue后可能追加清理逻辑 - 配合 clang-format / clang-tidy 等工具自动格式化时保持一致性
- 团队代码审查中减少“这里到底属不属于 if”的来回确认
对比写法：
// ❌ 危险（当前只有一句，但易被破坏）
if (ptr) delete ptr;
// ✅ 安全（显式界定，一目了然）
if (ptr) {
delete ptr;
}
为什么有人坚持不加？以及为什么这不可靠
部分人依据“C++ 允许省略”来省略，但现实中的代价远超几行字符节省：
-
if后接宏时极易出错，比如LOG_ERROR("fail");展开成多条语句就直接越界 - Git diff 中增删一行可能让缩进误导人，以为某行还在 if 内
- 静态分析工具（如 cppcheck）默认警告无括号单语句 if，关闭该警告等于主动放弃一层防护
- C++ Core Guidelines 明确推荐：ALWAYS use braces for if/for/while statements（ES.15）
嵌套 if 和 else 的配对问题会因此放大
没括号时，else 永远匹配**最近的、未被其他 else 占用的 if**。一旦中间插入新语句或调整缩进，配对关系肉眼难辨。
例如：
if (a) if (b) foo(); else bar(); // 这个 else 属于 if(b)，不是 if(a)
加上括号后，意图立即明确：
if (a) {
if (b) {
foo();
} else {
bar();
}
}
真正容易被忽略的不是“要不要加”，而是“加了之后，别人改代码时是否还敢动这块结构”。不加括号，等于把逻辑责任转嫁给每个后续修改者——而他们往往并不知道你当初的意图。
