在React项目里，大部分自动化测试和人工验证都沿着正常路径进行：接口返回200，组件按照预期props渲染，用户操作按固定顺序完成。可线上故障往往来自那些非正常组合，例如第三方接口超过5秒没有响应、全局状态在某个异步回调里被置空、某个组件遇到特殊数据格式直接抛错。混沌工程借鉴后端分布式系统的实践，把这些故障以随机、受控的方式注入前端运行环境，帮助团队在发布前发现React应用中的脆弱点。
一、为什么React应用需要混沌工程
前端韧性不只是接口重试或CDN切换，它体现在异常发生时应用还能不能给出可用反馈。React应用通常由大量组件、状态和异步任务组成，运行时越长，出现未知交互的概率越高。单元测试和集成测试可以覆盖明确的逻辑，但很难穷举真实用户环境中的网络抖动、内存不足、浏览器插件冲突等情况。混沌实验通过随机注入故障，把偶发问题转成可重复的验证场景。
和后端混沌工程不同，前端混沌注入可以更轻量。后端常常需要终止容器、占用CPU或断开数据库连接；前端则可以通过改写fetch、延迟Promise、让组件抛错、清空模块缓存等方式模拟异常。这些操作不需要复杂的基础设施，在开发环境或预发环境就可以完成。更重要的是，React本身提供了错误边界和Context机制，很适合构建故障注入层，而不必侵入业务逻辑。
需要注意的是，React错误边界并不能捕获所有错误。事件处理器、异步代码、服务端渲染、错误边界自身抛出的错误都不会被错误边界捕获。因此混沌实验还要配合全局的error和unhandledrejection监听，才能观察到完整的异常表现。韧性也不只看有没有报错，还要看用户是否能够快速恢复，比如错误提示是否清晰、重试按钮是否有效、页面是否还能局部使用。
二、设计可控的随机故障注入器
一个可用的前端混沌注入器需要满足三个条件：注入范围可控、失败概率可调、随机结果可复现。全局随机数很难定位问题，所以通常采用带种子的伪随机算法。每次实验使用固定种子，可以让同一条用例反复触发同样的故障组合；修改种子则可以探索不同路径。通过Context把注入能力暴露给组件树，业务组件只需要调用一个hook，无需关心注入细节。
下面是一个基础的ChaosProvider实现。它使用React的Context和useMemo创建带种子的随机函数，并通过shouldFail方法决定当前操作是否要注入失败。
import React, { createContext, useContext, useMemo } from 'react';
const ChaosContext = createContext({
enabled: false,
failureRate: 0.1,
random: function() { return Math.random(); },
shouldFail: function() { return false; }
});
function pseudoRandom(seed) {
let value = seed;
return function() {
value = (value * 9301 + 49297) % 233280;
return value / 233280;
};
}
export function ChaosProvider({ children, enabled = false, failureRate = 0.1, seed = 42 }) {
const random = useMemo(function() {
return pseudoRandom(seed);
}, [seed]);
const contextValue = useMemo(function() {
return {
enabled: enabled,
failureRate: failureRate,
random: random,
shouldFail: function(scope) {
if (!enabled) return false;
return random() < failureRate;
}
};
}, [enabled, failureRate, random]);
return React.createElement(
ChaosContext.Provider,
{ value: contextValue },
children
);
}
export function useChaos() {
return useContext(ChaosContext);
}在业务组件中使用useChaos，可以在渲染阶段主动抛错，模拟组件崩溃。为了让错误边界能够捕获这个异常，抛出动作需要发生在渲染期间，而不是事件回调里。这样就能验证错误边界的覆盖范围是否完整。
import { useChaos } from './chaos';
function ProductList() {
const chaos = useChaos();
if (chaos.shouldFail('ProductList.render')) {
throw new Error('注入的产品列表渲染异常');
}
return React.createElement('ul', null,
React.createElement('li', null, '商品A'),
React.createElement('li', null, '商品B')
);
}除了组件渲染失败，接口异常是最常见的故障类型。可以封装一个chaosFetch，在真实请求前加入随机延迟和失败判定。这样能模拟弱网、超时、服务端错误等场景，并观察组件在请求挂起或失败时的UI表现。
function chaosFetch(url, options, chaos) {
if (!chaos.enabled) {
return fetch(url, options);
}
const delay = chaos.random() * 800;
return new Promise(function(resolve, reject) {
setTimeout(function() {
if (chaos.random() < chaos.failureRate) {
reject(new Error('注入的接口请求失败: ' + url));
} else {
fetch(url, options).then(resolve).catch(reject);
}
}, delay);
});
}三、用错误边界和全局监听捕获注入异常
错误边界是React中处理渲染错误的主要机制。类组件中实现getDerivedStateFromError和componentDidCatch，可以阻止整个应用白屏，并展示降级UI。混沌注入的组件异常会被最近的错误边界捕获，从而验证错误边界的覆盖范围是否完整。如果一个故障导致整个页面崩溃，说明错误边界的位置或粒度需要调整。
class ErrorBoundary extends React.Component {
constructor(props) {
super(props);
this.state = { hasError: false, error: null };
}
static getDerivedStateFromError(error) {
return { hasError: true, error: error };
}
componentDidCatch(error, info) {
console.error('错误边界捕获:', error, info);
if (window.__chaosMetrics) {
window.__chaosMetrics.record(error.message, info.componentStack);
}
}
render() {
if (this.state.hasError) {
return React.createElement('div', { className: 'error-fallback' },
'当前模块暂时不可用，请稍后重试'
);
}
return this.props.children;
}
}错误边界无法捕获事件处理器和异步Promise中的异常，所以还要在window上注册error和unhandledrejection事件。混沌实验注入的接口失败如果被catch吞掉，就不会触发unhandledrejection，但如果没有catch，监听器可以记录到。通过全局监听，团队可以统计未处理异常的数量和类型。
window.addEventListener('unhandledrejection', function(event) {
console.warn('未处理的Promise拒绝:', event.reason);
if (window.__chaosMetrics) {
window.__chaosMetrics.record('unhandledrejection', String(event.reason));
}
});
window.addEventListener('error', function(event) {
console.warn('全局错误:', event.message);
if (window.__chaosMetrics) {
window.__chaosMetrics.record('window.onerror', event.message);
}
});为了量化韧性，可以在错误边界和全局监听中调用指标收集函数。记录每次注入是否被正确捕获、降级UI是否成功渲染、用户是否通过重试恢复。简单的统计可以包括：注入总次数、捕获次数、白屏次数、平均恢复时间。这些数据能直观反映React应用对异常情况的承受能力。
四、落地混沌实验的注意事项与韧性指标
混沌注入必须严格限制在测试、预发或本地环境，避免在生产流量上制造事故。可以通过环境变量控制ChaosProvider的enabled属性，默认关闭。失败概率也要从低到高逐步增加，例如从5%开始，观察应用表现后再提高到10%、20%。过高的故障率会让应用不可用，反而难以定位具体问题。
随机故障可能导致测试结果不稳定。使用固定种子运行关键用例，可以让失败可复现。例如在CI中设置种子为42，当某个混沌用例失败时，开发人员可以用相同种子在本地复现。故障范围也应该按模块划分，比如只对商品列表接口注入延迟，而不是同时让所有请求随机失败。这样可以避免多个故障叠加干扰判断。
韧性指标建议从两个维度定义：一是系统能否继续提供核心功能，二是恢复速度。比如商品列表接口失败后，页面是否展示了友好的错误提示并且提供重试按钮；重试成功后列表是否正常渲染。通过统计注入后的白屏率、错误边界触发率、重试成功率，可以给React应用打出一个相对客观的韧性分数。混沌工程不是要制造故障本身，而是通过受控的随机实验，让团队对系统的薄弱环节有更清晰的认识，并推动错误处理、降级策略和可观测性的持续改进。