企业官网建设流程全解析

2026年了，如果一个React项目的数据获取还停留在“能拿到数据就行”的阶段，那这个应用本质上就是在裸奔。我这里的“裸奔”不是说功能不能用，而是说性能优化和错误处理这两个关键维度，几乎被整个团队有意无意地跳过了。你打开Network面板，几十个请求没有超时、没有统一重试、没有错误上报；后端一抖动，页面不是白屏就是永远转圈；用户在网络差的环境下刷新，体验和第一次访问没有任何区别。这些场景，我相信做前端的人都不陌生。

这篇文章我想聊一个有点形象的框架——数据获取的第七层。这是我近两年在多个React项目里做技术梳理时常用的坐标图：前六层解决“请求怎么发、状态怎么管”，第七层解决“用户体验和系统稳定性怎么兜底”。绝大多数团队做到第三层第四层就觉得完成了，结果就是功能都能点，线上却在裸奔。如果你正在用React、React Query、SWR这类方案做数据获取，或者正打算重构数据层，这篇文章值得你读完。我不讲“多加几个依赖就完事”的套路，而是把性能优化和错误处理背后的真实逻辑拆开讲，配合代码和事故复盘。

1. 先给“第七层”定个坐标：数据获取的七个层级

“第七层”这个说法看起来有点玄，其实它对应一条很朴素的技术演进路径。任何一个React应用的数据获取体系，都可以按这七层去对号入座。

1.1 前六层是从“能跑”到“好维护”的进化

我列了一张简表，你可以对着看看自己的项目目前站到第几层：

前四层基本是“用法问题”，解决的是“能不能把数据拿回来、能不能让页面状态不乱”。到了第五层和第六层，就开始涉及“同一个请求重复发”“慢响应覆盖新响应”这些在真实项目中必然踩中的坑。真正的分水岭在第七层：当请求已经发出去、缓存已经命中了、竞态也已经处理完了，你是否还关心这次请求花了多久、失败了用户看到什么、后端连续抖动时系统会不会起死回生。

说实话，大部分团队到第三层就停了。第四层用了React Query但只当它是个“发请求的hook”，第五层的缓存参数全用默认值，第六层完全没听过。这样没什么好丢人的，因为第七层的价值只有在两个条件下才会爆发：一是你的用户量上来了，二是你的网络环境变差了。等到这两个条件同时满足，那种毫无保护的数据获取体系就会把问题全部暴露出来。

1.2 第七层为什么总是被跳过去

第七层容易被跳过，本质上是三个原因叠加的结果。

第一，它没有“唯一正确”的库。React Query解决了服务端状态，ErrorBoundary解决了渲染错误，但把一个请求从发出到渲染到上报到恢复的整条链路串起来，并没有现成的银弹，你需要自己设计和组装。第二，它的收益在开发环境完全看不出来。本地请求几十毫秒就返回了，缓存和数据新鲜度感知不到差别，错误处理随便写写也不会报错。第三，它的成本是隐性的。等你看到监控面板上白屏率上升的时候，往往已经过去了两周。

所以我说“裸奔”不是骂人，是一个客观状态。功能都在跑、页面都能打开，但一旦出问题，没有任何一层防护能替你挡住或者缓一下。接下来我把性能优化和错误处理分成两大部分，把第七层真正的内容拆开讲清楚。

2. 性能优化的四个真相：不是所有慢请求都是后端的问题

一说页面慢，前端第一反应是“后端接口慢”。但等你真的在第七层审视性能，你会发现很多慢并不是后端单独造成的，而是前端数据获取的姿势有严重问题。

2.1 请求合并与连接复用，比“加缓存”更接近本质

很多团队优化性能的第一反应是加缓存，但缓存解决的是“重复请求”的问题，解决不了“首次请求就一堆”的问题。以首屏为例，登录态、用户信息、菜单权限、列表数据、字典数据，如果每个都是独立的请求，代码写着很爽，浏览器层面的代价却很大。

HTTP/1.1下浏览器对同一域名有并发连接数限制，通常是6个左右。这意味着你发出去的第7个、第8个请求必须排队等着前面的连接释放。HTTP/2虽然没有这个限制，但真实项目里还存在网关代理、负载均衡等因素，大量并发请求依然可能触发服务端的连接数瓶颈。所以第七层性能优化的第一件事，是审视你的请求拓扑：能不能并行，能不能合并，能不能一次性把一组相关数据拿回来。

我分享一个在项目中用过的简单请求合并方案。它的核心思路是：短时间内的多个请求，聚合成一个批次发出，然后按调用方拆分结果。简单场景下，只需要一个带防抖的批处理队列：

const pendingBatch = new Map(); export function batchRequest(batchKey, requestFn) { return new Promise((resolve, reject) => { const queue = pendingBatch.get(batchKey) || []; queue.push({ resolve, reject }); pendingBatch.set(batchKey, queue); if (queue.length === 1) { requestFn().then( (data) => { const handlers = pendingBatch.get(batchKey) || []; pendingBatch.delete(batchKey); handlers.forEach((h) => h.resolve(Array.isArray(data) ? data.shift() : data)); }, (error) => { const handlers = pendingBatch.get(batchKey) || []; pendingBatch.delete(batchKey); handlers.forEach((h) => h.reject(error)); } ); } }); }

这个方案最典型的应用场景是字典数据、权限码或者批量详情查询。页面上一共有8个组件同时依赖一批字典项，过去是并发8个请求，现在合并成1个请求到后端批量查询，数据回来后再分发到各个调用方。实测下来，首屏请求数量直接从两位数降到了一位数，TTFB的总体等待时间也明显下降。

做这类优化时有一个原则：不要盲目合并所有请求，只合并业务上强相关、且允许后端一次性返回的数据。比如用户基本信息和用户权限属于强相关，可以合并；而列表数据和列表统计数字虽然都在一个页面，但更新频率不一样，强行合并会导致一个更新连累另一个，得不偿失。

2.2 缓存策略的默认值是“裸奔”的温床

我知道很多人用React Query，但大多数项目的配置是这样的：

const queryClient = new QueryClient();

一行的默认配置，用在全公司所有页面上。默认的staleTime是0，意味着数据只要被“读一次”，下一次再读就被认为是过期的，会重新请求。配合默认的gcTime，缓存数据在5分钟后被垃圾回收。这等于告诉React Query：几乎每次挂载组件都要重新请求。这就是典型的“用了缓存，却和没缓存一样”。

缓存的真正价值，不在于节省服务器流量，而在于让用户感觉“快”。用户在页面间切换、Tab来回跳转、筛选条件反复修改，如果每次操作都要面对Loading重新拉数据，体验一定不好。合理的做法是给不同业务的数据设置不同的新鲜期：

const queryClient = new QueryClient({ defaultOptions: { queries: { staleTime: 30 * 1000, gcTime: 5 * 60 * 1000, refetchOnWindowFocus: false, retry: (failureCount, error) => { if (error instanceof HttpError && error.status < 500) return false; return failureCount < 3; }, }, }, });

staleTime的语义是“数据在多少毫秒内可以直接复用，不需要重新请求”，它天然适合那种变更频率不高的数据，比如用户信息、系统配置、商品详情。gcTime则决定缓存对象在内存里待多久，它影响的是“切走再切回来时会不会命中缓存”。这两个参数一定要分开理解：staleTime是“新鲜度”，gcTime是“存活时间”。数据过期了但还活着，React Query会先返回旧数据，同时在后台重新请求，这叫“后台更新”，用户感知不到闪Loading。

我见过很多项目，代码里import了useQuery，却没有配置一套符合业务节奏的缓存策略，结果就是所有数据都在反复拉取。第七层的优化，很大程度上不是“写更酷的代码”，而是把这些默认值改到符合业务本身。给每个查询量身定制staleTime，才是真正能做很久的功夫。

2.3 渲染层消费数据的方式，决定了一秒和一百毫秒的差别

有几个性能问题，虽然发生在渲染阶段，但根源在数据获取。后端返回的数据来了，你需要把结果写入组件的响应式状态，再触发更新。如果你的页面结构是“列表数据 + 上千个子组件”，一次setState可能让整棵列表重新渲染，那再快的接口也白搭。

先说一个最常见的场景：用户在下拉框里筛选数据，你每次筛选都发一个请求，返回结果后整体更新表格。此时表格如果有几百行，每个单元格又关联着子组件，整个渲染链路会非常容易卡顿。React 18的并发特性其实有两个API可以帮上忙。

useTransition适合处理“把非紧急更新降级为可中断更新”。当你输入筛选条件并等待新数据返回时，这个新数据的落地不需要立即阻塞UI，你可以用transition标成低优先级：

const [isPending, startTransition] = useTransition(); const [list, setList] = useState([]); function handleFilter(filter) { setFilter(filter); fetchList(filter).then((data) => { startTransition(() => { setList(data); }); }); }

useDeferredValue适合处理“跟随某个高频变化值派生出来的数据”。比如你在图表页里调整时间范围，图表数据由这个时间范围派生，不必每次敲键盘都触发一次昂贵渲染：

const [range, setRange] = useState('7d'); const deferredRange = useDeferredValue(range); // 只有deferredRange变化时才去请求/重渲染图表

这两个API配合React Query的效果很好。React Query返回的data是稳定的，但当你把data塞给大组件树时，并发特性可以保证“数据来了”这个动作不会打断用户正在进行的操作，比如正在输入的文字、正在滚动的列表。

渲染层的数据消费方式，其实是对“数据获取性能”的最后一段接力。接口再快，数据落地的瞬间把UI卡死了，用户感受到的还是慢。第七层要求你从“请求发出”一路管到“DOM更新完成”，而不是只管到setState为止。

3. 错误处理：从“不崩溃”到“可恢复”的认知升级

如果说性能优化的第七层是“让应用跑得更轻”，那错误处理的第七层就是“让应用倒了还能爬起来”。这一层绝大多数项目更裸，因为业务代码里的错误处理实在太容易被“本地能跑”给麻痹了。

3.1 真实世界的错误类型，远比try/catch覆盖得多

我建议团队画一张错误分类表，把所有可能在数据获取链路里出现的错误列出来，然后再定义每一类该怎么处理：

很多团队在写数据获取代码时，习惯做一件事：catch到错误后直接弹个“网络错误”提示。这看起来在“处理”，实际上什么都没处理。4xx和5xx的含义完全不同，401和403的处理动作完全不同，你用一个“网络错误”把所有的错误信息稀释掉，用户看不懂，运维也没法排查。

第七层错误处理的第一步，就是在你的API客户端里做错误归一化。axios拦截器也好、fetch封装也好，先把底层错误翻译成带有status、code、message、timestamp的标准对象，再往上抛。这样业务组件只需要处理标准结构，而不是面对一堆长得不一样的Error实例。

3.2 静默失败：比崩溃更可怕的错误处理方式

有一种处理方式比“不处理”更危险，那就是静默失败。我见过一个真实案例：开发在请求列表数据的catch分支里写下了这样一行代码：

return [];

表面上看，接口挂了之后页面会展示空列表，至少不会白屏。但问题在于，用户看到的“暂无数据”和自己搜索后真的没有结果是两回事。前者是异常状态，后者是正常空态。应用把它们混在一起，用户就会反复刷新、反复重试、反复无功而返，最后形成一个很差的认知——“这个页面什么都没有”。

静默失败的可怕之处在于，它会污染数据。如果接口失败后你用了上一次的旧数据、用了默认的缓存、把部分字段填成null，后续的逻辑可能基于这些假数据继续运作。比如购物车组件请求失败后显示“购物车为空”，用户就会以为东西丢了，直接卸载App。

正确的做法是：请求失败之后，必须让错误“可见”。UI上要区分加载失败、空数据、部分数据三种状态；数据层要保留错误信息，抛给上层；日志层要把错误发出去。你可以使用ErrorBoundary兜住渲染阶段的崩溃，但数据获取阶段的错误必须交给错误状态管理，而不是吞进null里。

3.3 重试、取消与降级：第七层的基本功

错误处理的终极目标，不是“不发生错误”，而是在错误发生后让系统恢复可用。这里有三项基本功，缺一不可。

第一项是限制重试次数的指数退避。很多人的联网重试是这么写的：

catch (error) { setTimeout(fetch, 1000); }

固定一秒后重试，不限制次数。API连续挂了2分钟，你的客户端就每1秒打一次，不仅没有缓解问题，反而可能把后端压得更死。正确做法是指数退避，第一次失败后等500ms，第二次等1s，第三次等2s，最多到8s封顶，同时限制总次数：

async function fetchWithBackoff(url, options = {}) { const { retries = 3, baseDelay = 500, maxDelay = 8000, shouldRetry = () => true, } = options; let lastError; for (let attempt = 0; attempt <= retries; attempt++) { try { const res = await fetch(url); if (res.ok) return res; if (!shouldRetry(res.status, attempt)) return res; lastError = new Error(`HTTP ${res.status}`); } catch (error) { lastError = error; if (attempt === retries) break; } const delay = Math.min(maxDelay, baseDelay * Math.pow(2, attempt)); await new Promise((r) => setTimeout(r, delay)); } throw lastError; }

注意shouldRetry回调：只有当服务端状态码是500/502/503这类临时错误时才值得重试，遇到401、400这类不可恢复错误直接返回，别浪费时间和流量。

第二项是取消，也就是AbortController的规范用法。React 18的StrictMode在开发环境下会执行两次effect，如果你的数据获取没有做清理，就会发出重复请求。更关键的是，用户切换路由时，上一次请求的结果不应该再落地。很多人会在清理函数里写个flag标记组件是否已卸载，实际上更干净的做法是直接取消请求：

useEffect(() => { const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), 10_000); fetch('/api/list', { signal: controller.signal }) .then((res) => res.json()) .then((data) => setData(data)) .catch((error) => { if (error.name === 'AbortError') return; // 主动取消，忽略 setError(error); }) .finally(() => clearTimeout(timer)); return () => controller.abort(); }, [url]);

第三项是降级。降级不等于失败，而是用低配的数据流先保住核心体验。比如详情页里主接口挂了，但你可以先展示缓存里的旧版本详情，同时标注“数据更新失败，已显示上次内容”，给用户一个重试按钮。这个组合拳既让用户知道出了问题，又不至于完全空白，体感比“网络错误”四个字好太多。

4. 第七层的落地清单：性能监控、错误上报与兜底体验

有了前面的理论，现在说说怎么在项目里实际落地。第七层不是一个单独的功能模块，它是穿插在数据获取整个生命周期里的一套机制。

4.1 用Performance API把数据获取的时间拆开看

优化性能的前提是度量性能。你连哪些请求慢都说不清楚，优化就无从谈起。浏览器的Performance API天然提供了资源加载的时间线，而且不依赖外部SDK。

function collectFetchTimings() { const entries = performance.getEntriesByType('resource'); return entries .filter((entry) => entry.initiatorType === 'fetch' || entry.name.includes('/api/')) .map((entry) => ({ name: entry.name, duration: entry.duration, ttfb: entry.responseStart - entry.requestStart, download: entry.responseEnd - entry.responseStart, transferSize: entry.transferSize, protocol: entry.nextHopProtocol, })) .sort((a, b) => b.duration - a.duration) .slice(0, 20); }

TTFB是“首字节时间”，衡量从发请求到收到第一个字节的耗时，它主要反映网络和服务端处理速度，是排查慢接口的第一依据。download是“下载时间”，当transferSize很大时，能看出是不是返回数据体量超了。这两者对比，就能快速判断一个慢请求慢在服务端还是慢在数据体量。

把这些采集到的指标做成日志，按接口名聚合，再上报到监控平台，你就能得到一份“接口慢请求排行榜”。这个排行榜比任何经验直觉都准确，因为它直接来自用户真实环境的分布情况。

4.2 错误上报不是越多越好，学会采样和分级

错误上报系统在建起来之后，很容易陷入另一种裸奔：把前端所有错误无差别上报，结果监控平台全是垃圾噪音，真正的关键错误反而被淹没。我在项目里的经验是做三层分级。

第一层是“可忽略的噪音”：比如用户在无网环境下的fetch失败、用户主动取消请求、第三方脚本加载失败。这些错误不代表系统问题，不需要告警。第二层是“业务可恢复错误”：某个接口失败，但前端已经通过降级策略展示了旧数据或兜底UI，用户无感知。这种错误需要记录，但只需要统计聚合，不需要逐条告警。第三层是“需要立即响应的严重错误”：比如首屏核心接口连续失败、白屏率异常上升、ErrorBoundary频繁触发。

在上报侧，必须给错误打上采样率。对第二层错误，可以只上报10%的样本，用于趋势分析；对第三层错误，100%全量上报并且要及时通知。这样错误系统才不会变成筛子，真正出问题时你才能快速定位。

4.3 用户视角的兜底：骨架屏、乐观更新、局部恢复

第七层落地之后，用户在界面上感受最直观的就是三种兜底体验。

骨架屏解决的是“等待时不焦虑”的问题。它不是简单的CSS动效，而是要尽量贴合真实页面结构。列表页用卡片骨架，详情页用文字块骨架，组件级请求失败时，骨架屏要能平滑过渡到错误占位。React Query的isPending状态和Suspense配合，可以让骨架屏在数据到达前占据版面，避免页面跳来跳去。

乐观更新解决的是“明明用户已操作，却因请求慢被迫等待”的问题。最典型的是点赞、收藏、修改开关这类操作。理想体验是先更新本地状态，再发请求，失败再回滚。React Query的onMutate配合queryKey的缓存写入，可以把这种行为做成通用能力：

const toggleMutation = useMutation({ mutationFn: (id) => api.toggle(id), onMutate: async (id) => { await queryClient.cancelQueries({ queryKey: ['items'] }); const previous = queryClient.getQueryData(['items']); queryClient.setQueryData(['items'], (old) => old.map((item) => item.id === id ? { ...item, enabled: !item.enabled } : item) ); return { previous }; }, onError: (_error, _id, context) => { queryClient.setQueryData(['items'], context.previous); }, });

局部恢复解决的是“整体重试代价太大”的问题。一个页面有5个独立数据区块，其中一个挂了，不应该逼用户刷新整个页面。每个区块给独立的错误占位和重试按钮，配合该区块对应的query.refetch，用户点一下就能局部恢复。这不仅体验好，也避免整页刷新造成其他区块重复请求。

5. 复盘三个真实“裸奔”事故：根因定位与修复链路

技术细节讲了一大堆，最后我想复盘三个我实际处理过的问题。它们分别对应性能、错误、竞态三个方向，也都是第七层缺失时的典型症状。

5.1 弱网白屏：一个首屏请求链路被串行锁死的案例

现象是用户反馈弱网环境下首屏白屏时间特别长，最差能到8秒。最开始大家怀疑地图SDK加载慢，但实际上班同学用Chrome的设备模拟器弱网环境复现后，发现Network面板里首屏7个接口几乎是串行发出的——先请求登录态，登录态返回后再请求用户信息，用户信息返回后再去请求列表和权限。每一跳都是全链路RTT，弱网下每个接口耗时500ms以上，串行叠加自然就白屏了。

排查链路的突破口是把“请求依赖”画成一张有向图。发现部分接口其实是并行关系，只是写代码的人习惯性地await了一个再发下一个。修复方式很简单：用Promise.all把不相关的请求并行化，同时把登录态和用户信息两个强相关接口合并成一个批量接口。再配合骨架屏和staleTime缓存，弱网下的白屏时间直接降到2秒左右。这个事故给我最大的提醒是，很多性能问题根本不是公司没有性能优化能力，而是请求拓扑天然就是串行的，没人去审视它。

5.2 列表页“空荡荡”：500错误被静默吞掉之后

现象是某个列表页收到线上投诉：用户进来就是空列表，没有任何提示。排查发现接口其实返回了500，但前端代码的catch里直接返回了空数组。这导致页面展示了空状态组件，用户以为“数据不存在”，永远不知道是服务器暂时出了问题。更麻烦的是，相关错误没有任何日志，开发同学一开始根本不知道接口挂了，因为页面没有崩溃。

这一类问题的修复包含两步。第一是代码层的错误可见化，所有API catch必须把错误抛到统一错误处理模块，UI层根据错误码展示不同的降级内容；第二是监控层的建立，核心列表类的接口请求失败率达到阈值时要能触发告警，而不是依赖用户投诉。这次事故让我更加确信，静默失败远比高调的报错可怕，因为后者至少有人在处理，而前者会悄悄地消耗用户的信任。

5.3 搜索结果被覆盖：竞态响应的隐蔽性

现象是搜索页输入关键词后快速切换，比如先搜“react”再搜“vue”，最终展示的却是“react”的结果。一开始大家以为是后端查询逻辑有缓存，排查后发现是前端竞态：两个请求几乎同时发出，第一个请求在网络上慢了一些，后返回的数据覆盖了第一个请求的结果。由于不是每次都复现，开发环境网络快、延迟低，几乎不会触发。

修复竞态，我的优先级是：首选AbortController，在effect清理时取消上一次未完成的请求；做不到取消的场景，用请求序号或者最新请求时间戳做守卫。一个通用的守卫模式是这样的：

const latestRequest = useRef(0); useEffect(() => { const current = ++latestRequest.current; fetchData().then((data) => { if (current !== latestRequest.current) return; // 已经过期，丢弃 setData(data); }); }, [keyword]);

这类问题很隐蔽，因为它在开发环境很难复现，只有用户真实网络波动时才会触发。所以第七层的竞态处理必须前置，不要等出了问题再打补丁。

做第七层这一年多，我最大的体会是：数据获取的优化和错误处理，不是某一个技术点上的炫技，而是一条从请求发出一路延续到用户感知的链条。它需要你同时管好网络层、缓存层、渲染层和用户体验层。你不需要一口气全部做到，但至少应该知道，自己的应用目前在哪一层裸奔。先把请求拓扑梳理清楚，再把错误可见化，最后逐步补上监控和兜底，这条路走完，你会明显感觉到线上问题的处理速度不一样了。