一个看似“送分”的需求为何翻车？——前端状态机实战指南

源码太枯燥？一个人啃不动？关注公众号-「前端小卒」，让我做你的源码领读人。这里没有晦涩的说教，只有清晰的 Vue 3 & React 19 源码拆解。积跬步以至千里，小卒也能进阶为大将，我们一起过河！♟️

故事的开始总是惊人的相似。

上个月，需求评审会上，收到了产品经理的一个需求："做一个扫码支付弹窗。逻辑很简单：打开弹窗获取二维码，然后每隔 2 秒轮询一次接口，扫码成功就跳转，30 秒超时就让用户刷新"

一拍脑袋，凭经验判断，需求不难。作为一名熟练的"React工程师"，我极其自信地敲下代码，开始写需求代码。

const [isLoading, setIsLoading] = useState(false); // 加载二维码中
const [isPolling, setIsPolling] = useState(false); // 轮询接口中
const [isError, setIsError] = useState(false);     // 出错了
const [retryCount, setRetryCount] = useState(0);   // 重试次数
// ...后面还有一堆 useEffect 和 useRef 用来存定时器ID

当时的我还未意识到，这几个state给我带来了好几个bug单。

隐形的"状态爆炸"

正式提测之后，我就陆陆续续收到了好几个bug单。

"大佬，我就在网络卡顿的时候多点了几下'刷新'，页面就乱了"

浏览器的Network 面板上，几十个轮询请求在并发执行。UI 界面上，"正在加载"的转圈动画和"网络错误"的红字提示竟然同时存在，甚至还能点击"重试"按钮！！！

按照我的逻辑，isLoading 为 true 时，isError 肯定得是 false 啊。我明明写了 setLoading(true); setError(false)，为啥会出现这种问题！

为什么会失控？

问题的根源就在于试图用线性的逻辑，去对抗非线性的现实。

当 isLoading、isPolling、isError 三个布尔值混在一起时，理论上它们能组合出 2^3=8 种状态。而在真实的业务逻辑中，合法的状态可能只有 3 种（加载中、轮询中、失败）。那么剩下的那 5 种"不可能存在的状态"，一不小心没处理就会存在大量的缺陷。

我们花费 80% 的时间，不是在写业务，而是在写防御代码，去堵那些因为逻辑漏洞而产生的混沌状态。

面对那坨膨胀且脆弱的代码，再进行修修补补已经无济于事，必须要大刀阔斧式的推倒重来，和PM和运营沟通，需求进行延期，代码打回去重写。

解决此类问题的最佳方案，不是更高超的 if-else 技巧，而是一个经典的数学模型------有限状态机 。它的核心理念是：系统在任何时刻只能处于一种状态，且状态的流转是确定的。

引入有限状态机 (FSM)

绘制状态流转图

在写代码之前，我先画了一张图。这才是逻辑的核心：

流程图清晰的展示出来：

• 只有在 FAILURE 或 IDLE 状态下，才允许发起 FETCH。
• 在 LOADING 状态下，无论用户怎么点击，都不会触发多余的请求。

引入useReducer

React 的 useReducer 是实现状态机的绝佳工具，通过它可以将状态管理收敛到一个纯函数中。

定义状态与事件

// 状态枚举，只有这五种状态
const STATES = {
  IDLE: 'idle',
  LOADING: 'loading',
  POLLING: 'polling',
  SUCCESS: 'success',
  FAILURE: 'failure',
};

// 事件枚举：用户或系统能做的动作
const EVENTS = {
  FETCH: 'FETCH',      // 触发获取
  RESOLVE: 'RESOLVE',  // 成功拿到二维码
  REJECT: 'REJECT',    // 失败
  DONE: 'DONE',        // 支付完成
  TIMEOUT: 'TIMEOUT',  // 超时
};

编写 Reducer

这里使用双重 Switch 结构：先判断当前处于什么状态 ，再判断发生了什么事件。

const machineReducer = (state, event) => {
  switch (state.status) {
    case STATES.IDLE:
    case STATES.FAILURE:
      // 只有在空闲或失败时，才允许发起 FETCH
      if (event.type === EVENTS.FETCH) {
        return { ...state, status: STATES.LOADING, error: null };
      }
      return state; // 其他事件直接忽略！

    case STATES.LOADING:
      if (event.type === EVENTS.RESOLVE) {
        return { ...state, status: STATES.POLLING, qrCode: event.data };
      }
      if (event.type === EVENTS.REJECT) {
        return { ...state, status: STATES.FAILURE, error: event.error };
      }
      // 🔥 重点：这里没有处理 'FETCH' 事件。
      // 这意味着：在 Loading 状态下，无论用户怎么狂点按钮，代码都不会有任何反应！
      return state;

    case STATES.POLLING:
      if (event.type === EVENTS.DONE) return { ...state, status: STATES.SUCCESS };
      if (event.type === EVENTS.TIMEOUT) return { ...state, status: STATES.FAILURE, error: '超时' };
      return state;

    default:
      return state;
  }
};

组件层调用（分离副作用）

现在，组件层的代码变得异常清爽。我们只需要根据状态去渲染 UI，并利用 useEffect 处理轮询副作用。

const PaymentModal = () => {
  const [state, dispatch] = useReducer(machineReducer, { status: STATES.IDLE });

  // 业务动作：只负责派发意图，不负责判断逻辑
  const handleFetch = () => {
    dispatch({ type: EVENTS.FETCH });
    api.getQrCode()
      .then(data => dispatch({ type: EVENTS.RESOLVE, data }))
      .catch(err => dispatch({ type: EVENTS.REJECT, error: err }));
  };

  // 副作用管理：由状态驱动轮询
  useEffect(() => {
    let timer = null;
    if (state.status === STATES.POLLING) {
      timer = setInterval(async () => {
        const res = await api.checkStatus();
        if (res.success) dispatch({ type: EVENTS.DONE });
      }, 2000);
    }
    return () => clearInterval(timer);
  }, [state.status]); // 状态变了，副作用自动清理或重启

  return (
    <div>
      {state.status === STATES.LOADING && <Spinner />}
      {state.status === STATES.POLLING && <QRCode img={state.qrCode} />}
      {state.status === STATES.FAILURE && <ErrorView onRetry={handleFetch} />}
      {state.status === STATES.SUCCESS && <SuccessView />}
    </div>
  );
};

看懂了吗？我们不再修补漏洞，通过清晰的定义状态和触发事件，收敛业务代码复杂度，消除可能产生的bug。

---

深度解析状态机

写到这里，可能很多同学会问： "这不就是 Switch-Case 吗？为什么要叫它状态机？" 我们需要把视角拉高，从理论层面彻底理解它，以便应对更复杂的场景。

什么是有限状态机

有限状态机不是一种代码写法，而是一个数学模型。它由五个要素组成：

• 有限的状态 ：比如红绿灯只有红、黄、绿，不可能出现"红绿"。
• 有限的事件 ：比如"倒计时结束"、"按下按钮"。
• 转换规则 ：即 状态 A + 事件 B -> 状态 C。
• 初始状态 。
• 最终状态 。

它的核心理念就是：系统在任何时刻只能处于一种状态，且状态的流转是确定的。

为什么前端需要它

前端早已不是"展示页面"那么简单了，我们是在浏览器里跑 APP。以下场景如果不以状态机思维去写，迟早会崩：

• 多媒体播放器 ： 你以为只有 Play 和 Pause？错。 还有 Buffering（缓冲中）、Seeking（拖拽进度条中）、Ended（播放结束）、Error（加载失败）这些场景。
• 复杂的表单向导 ： 第一步 -> 第二步 -> 第三步。 用户在第二步点了"上一步"，数据怎么存？在第三步提交失败了，退回哪一步？
• TCP/WebSocket 连接管理 ： Connecting -> Connected -> Reconnecting -> Disconnected。 如果在 Reconnecting 期间用户手动点了"断开"，应该去哪？
• Canvas 游戏/交互可视化： 拖拽模式、绘图模式、选中模式。

读到这里，你可能已经热血沸腾，准备把项目里的所有组件都重写一遍。

且慢。

软件工程的核心在于权衡，如果需求仅仅是控制一个模态框的显示与隐藏，引入状态机只会增加无谓的代码复杂度。

那么，在实际业务开发中，我们应该依据哪些标准来判定是否需要引入状态机？当你的组件出现以下三种特征之一时，就可以结合业务适当的考虑重构了。

存在多个需要"手动同步"的boolean变量

这是最显著的信号。检查一下你的组件 State 定义，如果出现了两个及以上的boolean，且彼此之间存在逻辑关联，就需要警惕，当你需要维护多个布尔值变量的同步关系时，状态机是更优解。

例如：

// 典型的高风险代码
const [isLoading, setLoading] = useState(false);
const [isError, setError] = useState(false);
const [hasData, setHasData] = useState(false);

在这种结构下，开发者需要时刻警惕变量间的同步问题。比如在 setLoading(true) 时，必须记得同时重置 setError(false)。这种依赖"人为细心"来维护的代码，随着迭代周期的拉长，几乎必然会产生 Bug。

业务逻辑要求状态必须"互斥"

在很多场景下，业务状态在逻辑上是完全排他的。

比如开头的"扫码轮询"场景：一个请求不可能既在"进行中"又"已失败"。然而，如果使用分散的布尔值控制，代码层面是允许 { isLoading: true, isError: true } 这种非法组合存在的。

这种逻辑上的"排他性"如果不能在代码结构上得到强制保证，就会导致 UI 渲染出错（例如 Loading 动画和错误提示重叠显示）。所以如果UI展示依赖于严格互斥的状态（如 Promise 的 Pending/Resolved/Rejected），请尽可能的使用状态机强制约束。

状态流转路径有严格限制

简单的业务状态流转是自由的，而复杂的业务往往是有向图。

以"退款流程"为例：

• ✅ 合法路径：申请中 -> 审核通过 -> 打款中
• ❌ 非法路径：申请中 -> 打款中（跳过审核）

如果使用传统的 if-else 来防御非法跳转，代码中会充斥着大量 if (status === 'AUDIT_PASS') 这样的防御性判断。而状态机可以通过配置 transitions，天然地禁止了所有未定义的跳转路径。

所以当业务逻辑不仅仅关乎"当前是什么状态"，更关乎"当前状态允许变更为哪些状态"时，可以考虑引入状态机。

技术选型对照表

在开始写代码前，可以参考下表进行决策：

业务场景特征	推荐方案
简单的开/关状态 (Toggle)	useState(boolean)
简单的互斥状态 (Loading/Success/Error)	字符串枚举 (String Enum)
状态复杂，且存在特定的流转规则	状态机 (Reducer / XState)
涉及定时器、重试、取消等异步竞态问题	状态机 (推荐)

记住，工具是为了解决复杂度而生的。简单留给 useState，复杂留给状态机。

限制即自由

写烂代码的本质，往往是我们试图在混乱中保留过多的"自由度"。而优秀架构的本质，通常在于限制 。正如那句话说的：「喜欢就会放肆，但爱就是克制」

状态机严格规定了什么状态下能做什么事，这种克制提高了我们的前端稳定性。

最后送给所有的前端的一句话：

所有的 Bug，本质上都是 "非法的状态"或"错误的转换"。

TypeScript 帮我们在编译时静态地规避了非法类型，而状态机则帮我们在运行时动态地管理状态流转。

TypeScript + State Machine = 前端逻辑的绝对防御。