先聊个真实的场景。某团队接了一个跨平台订单处理系统的维护任务，刚开工就遇到了麻烦：一段下单核心逻辑有七层 if 嵌套，中间还夹着两个 for 循环，循环里又套着 switch，最里层还有一处 return 直接甩锅给调用方。同事打开代码第一句话是“这谁写的”。第二句话是“我不敢改”。不是不想改，是真的看不懂这段流程到底想干什么。这种问题，本质上是【流程控制】的设计缺失——代码的运行路径没有人提前规划，全靠后来者一层一层补丁堆缝，最终堆成一座没人敢碰的屎山。

这篇文章就围绕流程控制这个核心，把我在实际项目里拆过的分支、绕过的循环、处理过的异常、改造过的状态机，以及团队 Code Review 时反复踩中的坑，全部掰开揉碎讲一遍。你可以把它理解为一份流程控制的实战排雷手册，适合刚写了两年代码想往深走一走的人，也适合已经带项目、天天给小朋友擦屁股的组长看。

1. 流程控制混乱是项目的隐形杀手——先搞清楚它在工程里的真实定位

很多新手觉得流程控制不过就是 if 和 for，是编程语言自带的基础语法，有什么好讲的。这个想法大错特错。语法层面谁都会写 if，但不是谁都能设计出一条让后来人看得懂、让系统跑得稳、让排障成本足够低的执行路径。流程控制真正难的，不是“怎么写”，而是“怎么规划”。

1.1 流程控制在工程中的真实定位

流程控制这个词，说白了就是“程序下一步应该走哪条路”的决策机制。顺序执行、条件分支、循环迭代、异常跳转、并发等待、状态流转，全部属于流程控制的范畴。它不是某一个语法糖，而是所有代码都绕不开的骨架。你写的每一次函数调用，实际上都在做一次流程跳转；你写的每一个 if 判断，都在人为制造一条岔路；你写的每一个 try-catch，都在为意外路径兜底。

在工程层面，流程控制还意味着“可预期”和“可追踪”。一段好的流程控制，读代码的人可以顺着执行路径从头走到尾，每个分叉都有明确的判断依据，每条路径都有清晰的出口。一段烂的流程控制，读代码的人感觉像进了迷宫，每个拐角都可能凭空多出一条路，走出去全靠缘分。说句难听点的，判断一个项目代码质量好不好，不用看架构文档，随便抽一个核心业务函数看它的流程结构就知道了。

我见过太多项目，问题报表堆积如山，根本原因不是业务逻辑有多复杂，而是流程控制根本就没设计过。someone 在某个 fetch 回调里加了个 if，另一个人在外层函数开头又加了个 return，第三个人在循环里补了个 break。每次改动都只看局部，从不看整条流程走向。到最后，一套流程同时存在多种出口策略，有的地方成功了 return，有的地方失败了 return，有的地方异常了 return，到底是谁在什么条件下走到哪个出口，谁也说不清。

1.2 混乱流程的典型症状与代价

流程失控的项目通常有几个非常明显的症状。

第一个症状是“深嵌套”。代码一层套一层，if 里面套 for，for 里面套 switch，switch 里面再套 if。每个分支缩进四五个 tab，横向滚动条都拉到底了还没看到代码主体。深嵌套最大的问题不是难看，而是圈复杂度飙升，测试分支覆盖率根本做不上去，任何一个组合条件漏掉都可能在线上炸掉。

第二个症状是“重复判断”。同一个业务条件在入口处判断一次，在中间层又判断一次，在出口再判断一次。三个人各写一版，判断逻辑还不完全一致，有的加了一个前置条件，有的没加。这种重复判断特别容易制造“逻辑漂移”——你以为前后端的校验是一致的，结果两个版本已经在无人知晓的情况下分道扬镳了。

第三个症状是“散落流程”。一个完整的业务流程散落在五六个函数甚至三四个文件里，往上翻半天不找全。比如订单取消这个流程，入口在控制器里，业务判断在服务层，状态更新在数据库访问层，中间还穿插着通知和回调，读的人要同时打开四个文件才能拼出完整链条。

这些症状的代价是直接且惨痛的。第一，故障定位时间呈指数级增长。随便一个 bug 都要断点打一圈才能找到路径走向。第二，交接成本巨大。新人接手一个流程混乱的模块，往往需要一到两周才能理清脉络，期间产生错误修改的概率极高。第三，线上故障恢复慢。流程路径不清晰，回滚都不知道该回滚哪个版本。我在之前的项目中就遇到过类似的教训，所以后面做技术评审，只要看到三嵌套以上的代码，一律打回重构，没有任何商量余地。

2. 流程控制的四个基础件：顺序、分支、循环、异常，每个都有隐藏的坑

聊清楚流程控制为什么重要之后，我们进入正题。这节讲的四个基础件大家都会写，但真正能把这些基础件写对的人，说实话不多。每一件展开都有不少值得注意的细节。

2.1 顺序结构：被默认它最简单的人坑惨了

顺序结构没什么好讲的？恰恰相反。顺序结构最大的坑在于“隐式时序依赖”。A 函数执行完之后给 B 函数用，B 函数执行完的结果给 C 函数用，中间任何一环发生变化，后面的全部跟着错。这种问题特别容易出现在没有明确数据流的代码里——几个函数共享同一个全局状态，执行顺序一变，结果天差地别。

我之前处理过一个数据处理模块，三个步骤：清洗、转换、写入。数据清洗阶段会把临时结果塞进一个公共缓存对象，转换阶段再去读这个对象。后来有个同事为了“性能优化”，把清洗和转换的顺序调整了一下，程序也没有报错，就是结果全部变成了脏数据。排查了整整一天才发现是这个顺序的问题。所以顺序结构看似简单，但要遵循一个原则：依赖关系必须显式化，要么通过参数传递依赖的数据，要么通过在代码注释里明确标注执行先后顺序的约束原因。不要指望调用者会自觉遵守一个看不见的约定。

2.2 分支结构：别只会写 if-else，这些坑你大概率踩过

分支结构是流程控制里最常用的，也是最容易被写烂的。新手最容易犯的错误有三个。

第一个错误是条件覆盖不完整。只写了 if 满足某个条件做什么，没写 else 分支做什么，结果条件不满足的时候，程序悄悄地往下走，走到了完全不该走的路径。我经常举的例子是用户登录：if 用户名存在且密码正确，允许登录；但用户名不存在的时候，else 分支直接放行，结果用户带着一个空身份走进了业务逻辑。这种错误在 Code Review 里特别常见，因为人的注意力天然集中在“正常路径”上，忽略“异常路径”。

第二个错误是分支顺序错误。多个互斥条件用 if-else if 串联时，顺序就是优先级。排在前面的条件会吃掉后面的条件。尤其是条件之间有隐含包含关系的时候，顺序错了整个逻辑就全错了。举个例子，判断用户等级：if 积分大于 100 是中级用户，if 积分大于 1000 是高级用户。如果先判断大于 100，高级用户永远进入不了第二个分支。解决这个问题不难，把条件按从窄到宽、从特殊到一般的顺序排列即可。

第三个错误是“隐式判断”。什么是隐式判断？就是把一个条件拆成了多个语句，看起来每一句都没问题，合起来却表达了一个模糊不清的决策过程。比如先检查 A 是否存在，存在的话给它设置默认值，然后判断默认值是否满足条件。这种代码读起来费力，调试起来更费劲。要解决这个问题，最直接的办法是把条件提炼成一个有语义的变量或函数名，例如boolean canRefund = order.isPaid() && !order.isShipped();，一句话读懂判断意图。

2.3 循环结构：边界条件设计决定你半夜会不会被叫醒

循环结构的核心问题永远是三个：起始条件、终止条件、迭代方式。三者有一个搞错，就是无限循环或者漏数据。我实战中踩过最典型的一个坑是“差一错误”，循环条件里用了<还是<=，边界上的这一条数据就是进不来或者多跑一次。这种 bug 在单元测试里很容易漏掉，因为测试数据往往不会正好卡在边界上。

还有一类问题出在“循环内状态不清空”。循环体里用了一个临时集合，这一轮循环塞进去了数据，下一轮循环忘记清空，导致脏数据像滚雪球一样越来越大。在批量处理任务里，这种问题会直接导致结果整体错乱。

另外一个值得重点说的是循环里“提前退出”的控制。有些开发者喜欢在循环里加 return，条件满足直接退出函数。这不一定错，但会大大增加流程的理解成本。你阅读这段代码的时候得时刻记着想“它会在某个中间点直接结束，后面还有代码没执行”。如果循环出现多层嵌套，这种提前退出路径组合数会爆炸式增长，基本上没法手工验证全部路径。更稳妥的做法是设置一个状态变量，循环结束后统一处理结果，把流程控制在同一个出口上。

2.4 异常流程：被忽略的第三通道

顺序、分支、循环是在设计“正常流程”，异常处理负责的是“意外流程”。很多项目里，异常处理都是后补的，代码写完了才想起来 try-catch 一下。这种补丁式异常处理的后果是，异常路径根本没有纳入整体流程设计，catch 完不知道该往哪里走，要么吞掉异常继续跑，要么直接抛一个笼统的错误，把问题甩给上游。

异常流程设计至少要回答三个问题：发生异常后，当前这个状态应该是什么？错误信息应该怎么记录和传递？调用方应该收到什么样的反馈？三个问题不明确，异常处理就是贴着乱走，可能留下严重的隐患。

我说个具体场景。某团队处理一个文件导入功能，读取文件时抛了 IOException。开发随手 catch 了一下然后打了一条日志，return null。调用方收到 null 后直接往下走，把 null 当作空集合处理，结果用户看到导入“成功”但实际数据全部丢失。这个问题的根源不是 IOException 处理得对不对，而是异常发生后，流程没有及时终止，没有定义“导入失败”这个状态。正确的做法是：文件读取失败，捕获异常，记录错误，设置导入失败标志，直接中断后续流程，返回明确的失败原因，同时清理掉已读的半截数据。

3. 一次真实的流程控制改造实录：从嵌套地狱到表驱动状态机

理论讲完，上一段实操。我用自己的经历来拆解一次流程控制改造，涉及一个模拟的跨平台订单处理系统 X。这个系统原来的流程控制堪称反面教材，改造后清爽了很多。我把整个过程记下来，从问题分析到落地方案，一步不落。

3.1 原始代码问题定位

先看一段简化后的原始伪代码，感受一下这个系统的流程有多乱：

function processOrder(order) { if (order.status === 'CREATED') { if (order.paymentStatus === 'PAID') { if (order.stockConfirmed === false) { reserveStock(order); if (reserveSuccess(order)) { order.status = 'STOCK_RESERVED'; if (order.customerNotify === false) { notifyCustomer(order, 'processing'); order.customerNotify = true; } if (order.riskCheck === 'PASSED') { sendToWarehouse(order); order.status = 'WAREHOUSE_PROCESSING'; } else { order.status = 'RISK_REJECTED'; } } else { order.status = 'OUT_OF_STOCK'; } } else { order.status = 'STOCK_ALREADY_RESERVED'; // 这里逻辑已经乱了，库存状态和订单状态混在一起 } } else { if (order.paymentStatus === 'REFUNDED') { cancelOrder(order); } else if (order.paymentStatus === 'PENDING') { // 等待支付，什么也不做 } } } else if (order.status === 'WAREHOUSE_PROCESSING') { // 处理发货 } // 还有好几个 else if 分支... }

这段代码的问题首先在于把所有判断全部用 if 嵌套揉在一起。订单状态、支付状态、库存状态、通知状态、风控状态混在一个函数里，每个状态变化都直接修改 order 的字段，没有统一出口。找一条流程路径太费劲了。而且这里有隐式状态机——订单的状态流转本质上是状态机，但代码里完全没有状态机的概念，全靠状态字段组合判断。

3.2 第一步：梳理状态与事件，画状态迁移表

改造第一步是先脱离代码，用表格把订单从创建到完成的完整生命周期理清楚。我们定义了三个核心概念：状态、事件、动作。状态是订单当前处在什么阶段，事件是发生了什么外部或内部动作，动作是在某个状态下响应事件时要执行的行为。

这里用一个简化的状态迁移表来描述：

这张表就是流程控制的契约。状态只归状态，事件只归事件，动作纯粹是响应逻辑。有了这张表，后续代码怎么写都很难跑偏。

3.3 第二步：用表驱动状态机替代 if-else 嵌套

状态迁移表定好之后，代码改造就有了清晰依据。我们不再手写多层 if 嵌套，而是基于“当前状态 + 事件”查表获取动作和下一状态。工具语言是 Node.js，以下是改造后的代码结构：

const transitions = [ { from: 'CREATED', event: 'PAY_SUCCESS', action: reserveStock, to: 'STOCK_RESERVED' }, { from: 'CREATED', event: 'PAY_TIMEOUT', action: notifyTimeout, to: 'CLOSED_TIMEOUT' }, { from: 'CREATED', event: 'USER_CANCEL', action: closeOrder, to: 'CLOSED_CANCELLED' }, { from: 'STOCK_RESERVED', event: 'RESERVE_CONFIRMED', action: triggerRiskCheck, to: 'RISK_CHECKING' }, { from: 'RISK_CHECKING', event: 'RISK_PASSED', action: sendToWarehouse, to: 'WAREHOUSE_PROCESSING' }, { from: 'RISK_CHECKING', event: 'RISK_REJECTED', action: releaseStockAndNotify, to: 'RISK_REJECTED' }, { from: 'WAREHOUSE_PROCESSING', event: 'SHIPMENT_COMPLETED', action: notifyCustomer, to: 'COMPLETED' }, { from: 'WAREHOUSE_PROCESSING', event: 'SHIPMENT_FAILED', action: pushManualReviewQueue, to: 'MANUAL_REVIEW' }, { from: 'MANUAL_REVIEW', event: 'REFUND_CONFIRMED', action: refund, to: 'CLOSED_REFUNDED' }, ]; function transition(order, event) { const currentStatus = order.status; const candidate = transitions.find( (t) => t.from === currentStatus && t.event === event ); if (!candidate) { // 不允许的迁移路径，记录错误，触发告警 throw new Error(`非法流转: 状态 ${currentStatus} 不能响应事件 ${event}`); } const nextStatus = candidate.action(order); order.status = nextStatus; save(order); }

核心变化在于：每一条路径的合法性都被显式编码在表中，非法路径直接抛出异常，不会再像以前那样不知不觉地走到错误分支。新增业务状态只需要往表里加一条记录，不需要再改嵌套结构。读代码的人一眼就能看到所有合法路径。

3.4 第三步：回归测试与边界覆盖

这次的改造并非只是美观。我们用表里的每一行生成一个测试用例，保证所有状态和事件的组合都被覆盖到。同时补了一批“非法迁移”测试，针对表中不存在的组合，确认这些路径会抛错而不是默默忽略。比如“CREATED 状态下直接触发 REFUND_CONFIRMED”，“COMPLETED 状态下再次触发 PAY_SUCCESS”，这类场景全部拦截。

这里特别提醒一下：状态机表驱动改造最大的风险是遗漏了某个边界事件。原来 if-else 模式下，某些“非法组合”被静默忽略了，没有报错也没有处理。换成状态机后，这些组合一旦被触发就会抛异常。如果线上确实存在这种异常路径，改造后会直接暴露出来。所以回归测试的覆盖面一定要广，最好把真实生产环境里的操作日志拉出来，重放一遍历史事件，看看有没有非法组合出现过。我们当时拉取了近三个月的操作日志做事件重放，果然发现了几起“已关闭订单又触发通知”的旧问题，这些以前不会被发现，现在改造后可以在第一时间拦截下来。

4. 日常开发中最容易翻车的五个流程控制细节，每一个都是实战踩出来的经验

基础件和状态机聊完，我再把日常开发中那些琐碎但特别容易翻车的流程控制坑拎出来单独讲。这些坑不多，但每一个都真实存在，而且经常被认为是“玄学 bug”，实际查起来全都能落在流程控制设计缺陷上。

4.1 空值判断的顺序问题：先判断存在再判断值，顺序错了就白判断

这个坑在 Java 和 JavaScript 里非常常见。典型错误是这样的：if (user != null && user.name != null && user.name.length() > 0)看着没问题，但写反了就是if (user.name != null && user != null)，user 为 null 时直接抛空指针。顺序问题其实是一个短路求值问题，多条件用 && 连接时，前面的条件会决定后面的条件是否还会执行，前面的条件一旦不满足，后面直接跳过。

实际的建议是：永远把最前置、最基础的条件放在最前面，比如“对象是否为 null”永远排在“对象的属性是否满足条件”之前。同时能合并的判断尽量合并，减少链条长度。链条越长，忘记排雷的概率就越大。

4.2 循环里的 return：能不在循环里 return 就别 return

循环里 return 很常见，但很需要谨慎。常见场景是查找某条记录，找到了就 return。听着合理是吧？但循环里 return 意味着流程直接中断，后续的清理逻辑、统计逻辑全部跳过了。如果你这个循环除了找记录还要做计数、记录日志、更新缓存，一个 return 就把这些后置逻辑全吃掉了。

我处理过一个线上事故，定时任务里循环处理一批用户的积分，循环里有个“用户已注销就 return”的判断，结果用户 A 注销之后，A 后面的用户全部没有处理。排查下来发现就是循环里 return 造成的。这类问题的标准解法是：设置一个结果变量，循环里直接 continue 跳过无效记录，循环结束后统一处理结果。一句话总结：循环的出口越少，流程越好控制。

4.3 finally 与 return 的博弈：谁才是最后决定者

这是无数面试题里的经典问题，但很多人在真实项目里依然会写错。try-catch-finally 结构里，如果 try 块里有 return，finally 块里的代码依然会执行，而且如果 finally 块里也写了 return，它会覆盖 try 块里的返回值。也就是说，你写了return 1，finally 里写了return 2，函数最终返回的是 2。这类代码读者根本猜不到结果，流程走向完全不透明。

我的建议是：finally 块只放必须执行的清理代码，比如关闭连接、释放锁、删除临时文件，永远不要在 finally 里写 return 或 return 表达式。任何需要做结果判断的分支，放在 try 的出口后面统一处理。如果你发现自己在 finally 里做了业务判断，那就在告诉我你的流程设计出了问题。

4.4 并行流程的等待与超时：一个站点故障引发的超时雪崩

多线程和异步场景下的流程控制，核心问题就是等待、超时和取消。三个问题不处理好，一个依赖接口变慢，全套流程跟着卡住。我之前处理过一个调度任务：从三个数据源拉取数据，然后做合并。数据源 A 本身没问题，数据源 B 偶尔抖动，耗时从 200 毫秒变成 20 秒。由于没有给 B 设置超时时间，整个任务被 B 拖死，A 和 C 早就干完活了，结果还是要等 B 完成才能进合并流程。这就是流程控制的等待策略没设计好。

正确的做法是给每个并行子流程设置独立的超时时间，超时后走降级路径，比如使用默认值、跳过该数据源或标记部分成功。还要注意“整体超时”和“子任务超时”的区别：子任务可以允许部分失败，整体流程需要在整体时限内给出结果。这块没有通用答案，但原则是明确的：并行流程必须有超时、有降级、有汇聚策略，绝不能傻等。

4.5 幂等控制：流程重入和重复触发是隐形巨坑

幂等性指的是同一个请求执行一次和执行多次，结果是一样的。流程控制层面的幂等尤其重要，因为业务流程在超时重试、重复提交、消息重投等场景下，很容易被重复触发。订单支付回调就是典型：支付网关超时，客户端重试，回调被送了两次。如果代码里没有幂等控制，用户可能会被扣款两次，或者订单状态被两次更新互相覆盖。

幂等控制的做法一般有两个方向。一是“唯一键去重”，给每个流程实例生成唯一业务号，处理前先查这个业务号是否已存在，存在则直接忽略。二是“状态机约束”，用我们前面讲的状态迁移表来天然保证幂等：订单已经处于 COMPLETED 状态时再触发支付成功事件，直接走非法路径拦截，不会重复处理。前者适合外部接口的防重，后者适合内部状态流转的防乱。

5. 流程控制问题的定位实践：一个不靠猜的排查思路

线上出了 bug，最耗时间的环节往往不是改代码，而是定位“流程到底走到了哪”。这一节我把平时排查流程问题的完整思路整理成一套可复用的方法论，配合日志和断点使用。

5.1 流程“卡住不往下走”的排查思路

流程卡住是最常见的线上现象：调用发出去了，迟迟没有结果，界面转圈转了一分钟。第一步先看操作日志，确认当前停在哪一个环节。如果日志停在“请求进入 A 服务”，下一步就是看 A 服务是不是在处理中卡住了。这个时候我会在代码里定位对应的处理函数，条件断点打在函数入口，观察参数状态是否正常。

如果条件断点命中了，但函数内部没有后续日志输出，那问题就锁定在这个函数内部。我会重点排查三个位置：是否有等待锁的阻塞调用、是否有网络请求没设超时、是否有循环条件明明不满足却还在继续。特别是用了同步 HTTP 请求但没设置连接超时和读取超时的时候，API 是“看起来活着但实际已经不响应”的状态，由服务端超时引起的挂起最为隐蔽。排查第一件事就是确认这条链路上所有的 IO 调用都有明确的超时配置。

5.2 流程“走到不该走的分支”的排查思路

流程没卡住，但结果不对，走到了一条不该走的分支。这种问题的排查重点是“条件判断是否符合预期”。我经常用的方式是把分支判断里涉及的每一个参数值全部打出来，一个一个核。比如一段判断是if (status === 2 && type !== 3)，结果走了这个分支，那就检查 status 是不是真的等于 2、type 是不是真的不等于 3。很多一眼看是逻辑错误的问题，实际上都是数据污染问题——某个字段是 null、是空字符串、是带前后空格的字符串，导致比较结果和预期不符。

这种情况打日志时要打出原始值，而不是打处理后的值。比如你把输入先 trim 了一下再判断，那日志打的是 trim 后的值，你根本看不到原始值里有没有空格。先把原始值和处理后的值一起打出来对照，再决定是修数据还是修逻辑。

5.3 用 traceId 把散落的流程日志串成一条线

排查流程问题最大的阻碍是日志散落。一次完整的业务请求可能经过三四个模块，每个模块各打各的日志，每个日志都是孤立的，你只能靠时间戳大致拼一下。这个方法在请求量大、并发高的时候基本不可用。我强烈建议在入口处生成一个请求唯一标识，然后把它一路传递到所有链路层和日志输出里，查询时只需要按这个标识过滤，就能把一次请求涉及的所有模块日志按时间顺序刷出来。

这个唯一标识的方案实现成本不高，但收益极大。某团队在做订单系统改造时，给所有日志统一增加了 traceId。排查从平均一小时缩短到了十几分钟，效率提升是几何级别的。流程控制的另一个价值也体现在这里：只要路径规划清楚了，每一条路径都能完整追踪，故障定位就成了一件确定性的事情，而不是赌运气。

6. 把流程控制写进团队规范的实践心得

文章写到这里，我想最后聊的已经不是技术本身，而是流程控制的工程执行力。很多团队不是不知道这些道理，代码评审的时候也能指出别人写的问题，但自己的代码一写起来又回到老路。问题的关键不在于懂不懂，而在于有没有把流程控制的要求沉淀成团队规范并强制约束。

6.1 团队红线：四条必须遵守的流程控制原则

来源是某团队的踩坑总结，经历过了三重崩溃后，定下来的四条铁律。第一，任何函数的圈复杂度不能超过 10，超过的必须拆解重构，圈复杂度超了就说明流程分叉太多，人脑已经无法完整覆盖验证。第二，嵌套深度最多允许三层，再深就必须用守卫子句或状态机提前返回，三层以上直接打回。第三，循环里禁止直接 return 修改外层状态，只能通过 break、continue 和状态变量控制。第四，异常处理禁止吞掉异常后继续正常流程，任何一个 catch 块都必须明确定义错误状态，要么中断流程，要么走降级路径。

这些红线不是凭空拍脑袋定的。每一套都是来自真实的线上故障复盘，每一条背后都有对应的血的教训。有了这些硬性的约束，代码评审就不再靠个人审美和经验来把关，而是靠一套可视化的规则严格执行。

6.2 Code Review 里最常被挑战的五个流程控制问题

在代码评审的实操过程中，以下五个问题是出现频率最高、争议也最多的，列出来给大家做参考。

第一个问题：你这个函数的退出点有几个？如果超过三个，大概率需要重新设计。多个退出点意味着调用方必须理解每个退出场景，理解成本极高。第二个问题：这个 else 分支为什么没有处理逻辑？如果不需要处理，请显式说明原因，而不是放任程序静默向下走。第三个问题：这个循环里的 break 和 continue 条件是否覆盖了所有边界？漏掉一个边界就可能导致死循环或漏数据。第四个问题：这个 catch 块里的错误数据有没有清理现场？临时状态不清空，下一次执行可能带着上次的残留数据继续跑。第五个问题：这段异步流程的超时时间是多少？别用默认值糊弄，每个远程调用都应该显式指定超时并评估降级方案。

6.3 从代码层面构建更稳的流程控制

这部分我分享几个可以直接套用的代码模式。卫语句你可能用过，但值得反复强调：尽早返回，把异常路径在前序直接拦截掉，让后面的主流程保持一条直线。主流程越短越直，排障时越容易追踪。另一个是策略模式：如果你的代码里出现了多个 if-else 分支，每个分支做的事情完全不同，那就用一张映射表或者策略替代那一长串判断分支。前面讲的状态机就是一种特殊的策略组织方式。

我个人认为流程控制是一个代码能否被称为“可维护”的分水岭。一段业务逻辑的执行路径写得清清楚楚，后续的一切都好谈：测试覆盖能做到位，排障效率有保障，新人接手成本低。相反，路径混乱的项目永远在临时救火的状态里反复横跳。反正我经历过的几次大型重构，最后追根溯源，问题几乎都出在一开始的流程划分阶段。这也让我养成了习惯：写代码前先画路径，把分支理顺后再动手。泥地里开车的故事听多了之后，我自己先遵守，团队再跟着做，项目整体质量就好控制得多了。