条件顺序影响执行与结果：短路求值使左侧优先执行，安全检查须前置；if-else if需从严格到宽松；构造函数初始化顺序取决于成员声明顺序而非列表书写顺序。
多个条件用 && 连接时，顺序影响执行和结果
会，而且影响很实在：短路求值（short-circuit evaluation）让左侧条件先执行、右侧可能根本不执行。一旦左侧为 false，整个表达式就确定为 false，右侧直接跳过。
常见错误现象：访问空指针或未初始化对象时崩溃，比如写成 ptr->data > 0 && ptr != nullptr —— 看似逻辑对，但实际先解引用 ptr，再判断是否为空，已经段错误了。
- 正确写法必须把安全检查放左边：
ptr != nullptr && ptr->data > 0 - 涉及函数调用时也一样：
isValid() && expensiveCheck()中，expensiveCheck()可能完全不被执行 - 性能影响明显：把开销小、失败概率高的条件放前面，能有效减少不必要的计算
多个条件用 || 连接时，顺序决定“谁先赢”
|| 同样短路：只要左边为 true，右边就不执行。这在设置默认值、兜底逻辑里特别关键。
使用场景：比如读配置项，优先用环境变量，没有再 fallback 到硬编码值：getenv("PORT") != nullptr ? atoi(getenv("PORT")) : 8080 是安全的；但如果写成 atoi(getenv("PORT")) || 8080，getenv("PORT") 返回 nullptr 时传给 atoi 就 UB 了。
- 真实踩坑点：
file.is_open() || file.open("default.txt")想表达“如果没打开就打开”，但||左边为true时右边根本不会执行 - 想实现“或操作+副作用”，得用
if显式控制，不能依赖||的求值顺序来触发逻辑
if-else if 链中条件顺序错位导致逻辑被跳过
这不是短路问题，而是分支匹配机制：从上到下依次判断，命中第一个为 true 的分支就进去，后面全忽略。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
典型错误：把宽泛条件写在前面，窄条件永远进不去。例如成绩分级写成：
if (score >= 60) { /* 及格 */ }
else if (score >= 90) { /* 优秀 */ }
那 95 永远只会进第一个分支，第二个根本没机会。
- 正确顺序必须从严格到宽松：
>= 90、>= 80、>= 60、else - 边界重叠时尤其危险，比如
score > 90和score >= 90混用，90会落到哪个分支取决于谁在前 - 调试时加日志发现“某分支怎么从来不走”，八成是顺序或边界写反了
构造函数初始化列表里的顺序不是书写顺序
这个“顺序影响结果”最隐蔽：初始化列表里写的先后顺序完全无效，真正顺序由成员变量在类中声明的顺序决定。
容易踩的坑：你写 A(int x) : b_(x), a_(b_ + 1)，以为先初始化 b_ 再用它算 a_，但如果类里是 int a_; int b_; 声明的，那 a_ 会先构造——此时 b_ 还没初始化，a_ 被赋予的是垃圾值。
- 编译器通常只发 warning（如
-Wreorder），不报错，运行时行为未定义 - 查这个问题得翻头文件看声明顺序，而不是看构造函数里怎么写的
- 一旦涉及跨成员依赖，必须确保声明顺序与逻辑依赖一致，否则无解
复杂点在于，有些顺序影响是运行时可见的（比如空指针崩溃），有些是编译期静默的（比如初始化顺序错乱），还有的只在特定数据路径下暴露（比如 if-else if 分支漏匹配）。别依赖“看起来对”，得盯住语言规则本身。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
