应避免在if-else分支中直接执行副作用操作，须明确每条路径的完整状态契约、分离判断与执行、使用不可变结构、强制兜底并辅以静态检查与测试。
直接在 if-else 分支里做赋值、状态更新、I/O 或对象修改等副作用操作，容易造成数据断层——即某条路径没走、某次修改被跳过、或多个分支重复改同一变量，最终导致程序状态不一致、难以复现的 bug。关键不是“能不能写”，而是“怎么写才不会漏、不会重、不会歧义”。
明确每条路径的完整状态契约
每个分支都应视为一个独立的状态转换单元。不能默认“其他分支已设好某个值”，而要显式声明本分支下所有相关变量的终态。
- 避免只在 if 里赋值、else 里不处理（尤其在 Verilog 或状态机中会隐式生成锁存器）
- Java/Python 中不要写：
if (valid) user.status = "active";—— 缺少 else 时，status 可能保持旧值或 null，下游逻辑误判 - 正确做法是：每个分支都覆盖目标变量，或统一初始化后仅修改差异项
（例）user.status = "inactive"; if (valid) user.status = "active";
副作用操作与条件判断分离
把“判断该不该做”和“实际去做”拆开，中间用纯数据承载决策结果，降低耦合和遗漏风险。
- 先计算动作标识：
bool shouldUpdate = (user != null && user.isEligible()); - 再集中执行：
if (shouldUpdate) { saveToDB(user); logAction("update"); } - 好处：判断逻辑可单独测试；多个副作用可批量触发；调试时能直接打印
shouldUpdate看是否符合预期
用不可变结构或副本隔离副作用范围
当分支需修改复杂对象时，避免原地修改引发上游/下游读取不一致。优先返回新状态，而非修改旧引用。
- 不用：
if (isUrgent) task.priority = HIGH; else task.priority = LOW; - 改用构造新对象或使用 builder：
Task updated = task.withPriority(isUrgent ? HIGH : LOW); - 函数式风格下，副作用只发生在最外层消费点，中间全是纯计算，天然规避断层
强制兜底 + 静态检查辅助
靠人眼盯住所有分支太不可靠。引入机制确保无遗漏：
- 语言层面：启用编译器警告（如 Java 的
-Xlint:fallthrough，Rust 的 exhaustive pattern matching） - 代码规范：要求所有 if 必须带 else；多分支用 switch/case 并强制 default
- 单元测试：对每个分支跑一次，断言不仅看返回值，还要检查所有被修改变量的终值
- 日志埋点：在每个分支入口打 trace 日志，运行时一眼看出哪条路径没触发
