前端Mock翻车复盘：从Fetch拦截到本地Mock的工程化方案

那天下午三点多，我做了一件看上去特别正常的事：统计中心的后端接口还没就绪，前端排期又压在demo前必须跑通，我从老项目里复制了一份mock JSON，丢进公共Mock平台，然后在自己负责的模块里加了一行全局fetch拦截。当时我甚至没意识到，这行代码不是“测试辅助”，而是货真价实的炸弹引信。不到48小时，统计中心的详情页白屏、列表页超时、两个原本已经就绪的真实接口也一起被拖垮。这场因为Mock测试翻车引发的连锁事故，让我真正开始审视前端开发者工具这件事：大多数人嘴上说“要重视”，实际使用却极其随意，包括之前那个自信满满的我。

如果你也是那种“后端没给接口就先Mock一下”、平时直接用公共Mock平台、在组件里随手拦截请求的前端，这篇文章值得读完。我会完整复盘这次事故的来龙去脉，把mock文件到底怎么组织、export default为什么这么写、模块级拦截和网络层拦截怎么选、公共平台不稳时怎么办这些细节一次讲透。后面还会给一份我事后沉淀下来的工具与规范清单。

1. 一次自认为“稳了”的Mock决定，是如何在两天内连环翻车的

先还原事故现场，方便你对照自己的项目找共性。

1.1 从“能出数”到“页面白屏”的几十个小时

我们那个统计中心做的是数据面板重构，拆成三个接口：/api/statistics/summary（汇总卡片）、/api/statistics/trend（趋势图）、/api/statistics/breakdown（分类明细）。周五要demo，周三下午问后端，只有前两个接口好了，breakdown还在联调。按老规矩，这个接口先用Mock顶上。

我的操作过程如下：

• 从老项目里找到一个看起来“长得很像”的历史JSON，复制到公共Mock平台。
• 在新项目组件文件顶部插了一段window.fetch拦截逻辑，命中/api/statistics前缀就走mock，其余请求放行。
• 跑了一下页面，列表和汇总卡片能出数，自己觉得没问题，提交代码去了。

晚上九点多，同事在联调环境打开详情页，页面直接白屏。控制台报错信息指向一行很无辜的代码：stats.breakdown.map(...)，而实际返回的数据里根本没有breakdown字段，老项目那个字段叫items。更深一层的问题在于，老项目那条数据的嵌套层级和当前接口定义也不一致，顶层结构看着像，子级完全对不上。

到这里还只是数据结构错误，属于常见问题。我改完JSON结构，本地验证通过，就以为收工了。第二天上午才是最要命的：演示用的环境里，统计中心整个页面的请求全都pending，连汇总卡片都加载不出来。查了很久才发现，不是后端接口出了故障，而是我前一天依赖的那个公共Mock平台访问不稳定，那个mock地址一直在超时。更打脸的是，我前一天写的“全局fetch拦截”把整个项目里所有以/api/statistics开头的请求全部劫持了，包括后端已经就绪的两个真实接口。也就是说，不管真实服务好不好，前端请求都会先被拉到Mock平台，而Mock平台一旦访问异常，全页面直接瘫痪。

1.2 复盘：一次Mock为什么能演变成事故

单看每一步，都很蠢，但叠加在一起就是典型的前端事故路径。

第一个根因是mock数据失真。我验证mock时只看页面有没有被填充上数据，没有对照当前接口的契约文档逐层核对字段。老项目的数据结构相似不等于一致，而前端对数据结构的信任一旦落空，通常会直接白屏。这也是Mock测试最致命的地方：很多团队把mock数据写得很随意，总觉得“反正是假的，先跑通再说”。

第二个根因是拦截范围失控。我直接把window.fetch替换成了自己的包装函数，意图是“只拦截统计中心的请求”，但判断条件是前缀匹配，实际把所有统计请求都吞进去了。前端组件的模块边界是清晰的，可window.fetch是全局的，一旦动手改造，就相当于在全局规则里插了一条“我们也不知道会影响谁”的隐形逻辑。

第三个根因是公共Mock平台本身变成了单点。当mock地址写在代码里、事务跑在别人的公共服务上，这个服务的稳定性就不受我们控制。之前的几次小抖动因为并发低没被发现，偏偏在演示前一天这种最需要稳定的节点出了问题。

第四个根因最隐蔽：我们的业务组件没有任何兜底。没有ErrorBoundary，没有请求失败的空态，没有对响应结构做运行时校验。接口只要返回一个与预期不符的结构，render过程直接抛异常，整棵组件树被卸载，呈现出来就是一个干干净净的白屏。后端接口如果字段少了一个，前端代码根本无法提前感知。

这四个问题单独拿出来都不难修，难的是它们几乎不可能靠“多写几行测试”解决，它们要求你对前端开发者工具有一个更系统的理解。

2. 先把Mock的本质问清楚：它到底在替我们解决什么问题

翻车之后，我第一件事是冷静下来重新认识Mock。它不是“造假数据”那么简单。

2.1 Mock测的不是数据，是“依赖不可用”时前端的存活能力

在统计中心这种场景里，Mock真正解决的是依赖问题。后端接口没准备好、测试环境数据太少、第三方平台不回复，前端不能干等着，需要有一个可控环境把开发、验证、联调三个动作串起来。

使用Mock的典型场景其实很集中：

• 后端接口进度落后，前端要提前并行开发，且不想写死临时UI。
• 需要稳定复现一些边界情况，比如空列表、超长文本、金额为0、接口报错。
• 自动化测试不能每次都请求真实后端，容易受网络和脏数据影响。
• 演示环境或UAT环境不稳定，需要给业务方一个确定性的展示。

统计中心的场景属于典型的第一类。我过去面对这类需求时默认动作就是“Mock一下”，但很少去想：Mock虽然解决依赖问题，同时也把“真实依赖”替代成了“仿真依赖”，而仿真永远有失真风险。问题不在要不要Mock，而在你能不能清楚说出失真的边界在哪里。

2.2 “仿真”的两个失真源：结构失真与时序失真

围绕这次翻车，我总结出Mock最容易骗人的两个地方。

结构失真最好理解。前后端基于接口文档协作，接口文档里写的是breakdown: BreakdownItem[]，而老项目返回的是items: Array<{...}>，在页面上看起来都有数据能渲染，但一旦组件读某个深层字段，结构差异会立刻暴露成异常。结构失真不只是“字段没对上”，还包括类型不对、层级多套了一层、数组和对象被放反了——这些问题在静态代码里很难发现，只会在运行时炸掉。

时序失真更隐蔽。真实后端通常要查库、算指标、走网络链路，响应时间少说几百毫秒；Mock数据如果直接放内存里返回，基本是零点几毫秒。于是你会看到一种假象：列表加载动画一闪而过，分页切换极其流畅，使用者觉得体验很好。等真实接口一接上，网络波动的loading态、竞态条件、超时重试全都冒出来，测试时根本没覆盖到。同样，真实接口会有5xx、4xx、网关超时，而大多数Mock只写了成功的happy path，错误处理几乎为零。这次翻车后同事问我：为什么连“接口访问不了”这种错误都没页面没处理好？因为Mock把这类错误路径完全藏掉了。

2.3 工具越顺手，人越容易交出防御责任

还有一个心理层面的原因值得讲。Mock工具的初衷是降低仿真成本，但门槛越低，人就越容易把本该自己负责的部分外包给工具。我常说，工具能帮你生成一个假接口，它不能帮你判断这个假接口覆盖了哪些真实行为。

前端开发里存在一种“约定优于验证”的氛围：后端说了字段是total，前端就默认total一定存在。接口文档没变，可Mock数据的嵌套错了，代码还察觉不出来，等到用户真打开页面才炸。Mock工具链如果只负责“生成数据”，不负责“验证数据”，实际上是把安全问题推给了运行时。这在业务快速迭代时还能忍，但一旦到了演示前夜这种高压时间点，任何一环出错都会被放大。

统计中心的事故就是最好的反面教材：我对mock数据结构的信任，超过了对接口契约的验证；我依赖公共平台的稳定性，超过了对本地环境的掌控。专业和不专业的差别，往往就藏在这些“默认没事”的瞬间。

3. 把Mock做稳的最小方案：独立JS文件、export default与拦截层选型

复盘归复盘，真正要紧的是给出一套可以直接落地的写法。关于“mock独立js文件要怎么写export default”，我猜不少人在搜索框里敲过这句话，因为网上99%的教程只讲“怎么用Mock平台”，不讲代码仓库里的mock文件怎么组织。这节重点讲透。

3.1 独立JS文件的标准结构与export default用法

我最推荐的方式是：把mock数据放进项目根目录下的mocks/文件夹，每个业务模块一个文件，与业务代码同步参与版本管理。文件里的数据结构尽量贴近真实接口的返回，不写死太多与接口无关的字段。

js复制// mocks/statistics.js
// 用法：业务代码里执行 import statisticsMock from '@/mocks/statistics'
// 匹配 /api/statistics/breakdown 接口的数据

function randomBetween(min, max) {
  return Math.floor(Math.random() * (max - min + 1)) + min;
}

function generateBreakdown(length = 6) {
  const categories = ['流量', '转化', '留存', '收入', '活跃用户', '新增用户'];
  return Array.from({ length }, (_, index) => ({
    category: categories[index % categories.length],
    value: randomBetween(100, 5000),
    ratio: Number((Math.random() * 30).toFixed(2)),
  }));
}

const statisticsMock = {
  code: 0,
  message: 'success',
  data: {
    total: 128,
    breakdown: generateBreakdown(),
    updatedAt: new Date().toISOString(),
  },
};

export default statisticsMock;

这里有三个值得展开的细节。

第一，我习惯把mock文件里的对象命名为带Mock后缀的具名常量，最后再export default。直接写export default { code: ... }也没错，但少了变量名，以后想引用内部其他函数会很别扭。

第二，mock数据不是越真越好。真实接口返回的字段可能很多，mock只保留界面真正使用的那部分即可。保留过少也不行——如果组件已经读取了某个字段，mock里却没有，同样会白屏。标准做法是：mock字段集合必须覆盖当前前端代码引用的所有字段，同时与接口文档核对至少一遍。这个“核对一遍”无法被工具替代，但后续可以用Schema校验兜底。

第三，如果mock数据还需要被多个测试文件复用，可以支持传入覆盖项，让测试用例能构造不同的分支数据：

js复制export function createStatisticsMock(overrides = {}) {
  return {
    code: 0,
    message: 'success',
    data: {
      total: 128,
      breakdown: generateBreakdown(),
      updatedAt: new Date().toISOString(),
      ...overrides,
    },
  };
}

export default createStatisticsMock();

注意这里的用法差异：createStatisticsMock是工厂函数，默认导出的是一个直接创建的实例。哪种更好？我的实践结论是：mock文件的默认导出保持“数据”语义，因为业务代码和MSW handlers引用时默认把它当数据用；需要造不同分支数据时，才单独引入工厂函数。这样能避免“导出一个函数，有人直接当成数据渲染”的可笑事故。

3.2 为什么是export default，而不是export const或module.exports

热搜词里专门有人在搜“export default”，说明这是很多人的卡点，值得多花点篇幅。

ESModule是ES6引入的模块标准，规定每个模块可以有默认导出（default export）和若干命名导出（named export）。默认导出对应import xxx from './mocks/statistics'这种写法。只有默认导出的内容，才能被“不带花括号”的import直接接住。

不少人会把mock文件写成这种形式：

js复制export const statisticsMock = { ... };

然后调用方也写得不对：

js复制import statisticsMock from '@/mocks/statistics'; // 报错：没有默认导出

这里会报SyntaxError: The requested module does not provide an export named 'default'。命名导出必须用命名导入：

js复制import { statisticsMock } from '@/mocks/statistics';

还有人习惯在浏览器环境继续写CommonJS的module.exports = { ... }，这在纯Node环境没问题，但在Vite/Webpack的浏览器环境里会踩兼容坑，尤其是如果你在mock文件里同时混用module.exports和import，构建器往往会给出很误导人的错误。

正确的默认导出写法有两种完全等价的格式，看你团队习惯：

js复制// 写法一：定义变量后导出
const statisticsMock = { ... };
export default statisticsMock;

// 写法二：直接导出一个表达式
export default { ... };

写法一更利于调试时定位变量来源，也方便在一个文件里同时导出多个具名mock数据。当mocks/statistics.js包含多套分支数据时：

js复制const emptyStatisticsMock = {
  code: 0,
  data: { total: 0, breakdown: [] },
};

const errorStatisticsMock = {
  code: 500,
  message: '服务异常',
  data: null,
};

export { emptyStatisticsMock, errorStatisticsMock };
export default {
  code: 0,
  data: { total: 128, breakdown: generateBreakdown() },
};

需要强调的是，export default并不强制要求一个模块只导出一个东西。一个文件可以同时有默认导出和命名导出，放在mock文件里就是：默认导出最常用的“标准数据”，命名导出各种“边界数据”。这样不同的调用方可以按需取用，不会因为一份mock数据被多个场景共用而互相污染。

3.3 模块级拦截：把Mock放进业务封装的请求函数里

有了mock文件，下一步是决定你在哪里“切入”mock逻辑。如果只想在同一模块内部生效，最简单的方式是把请求函数单独封装，mock分支不出这个函数。

js复制// services/statistics.js
import statisticsMock from '@/mocks/statistics';

const ORIGINAL_FETCH = window.fetch.bind(window);

function isStatisticsUrl(url) {
  return typeof url === 'string' && url.includes('/api/statistics');
}

export function fetchStatisticsBreakdown({ useMock = true } = {}) {
  if (useMock) {
    return Promise.resolve.statisticsMock; // 假设这是异步请求，直接返回resolve即可
  }
  return ORIGINAL_FETCH('/api/statistics/breakdown')
    .then((response) => {
      if (!response.ok) throw new Error(`HTTP ${response.status}`);
      return response.json();
    });
}

实际项目中会用Promise.resolve包一层：

js复制if (useMock) {
  return Promise.resolve(statisticsMock);
}

模块级拦截最大的好处是影响范围可预期。services/statistics.js里只处理统计模块的请求，不会殃及其他模块。翻车那天的问题恰恰出在全局fetch拦截上，所以我现在强烈建议：除非你写的是PWA离线缓存这类真正需要全局控制的逻辑，否则别轻易重写window.fetch。

如果你所在的团队已经使用axios：

js复制import axios from 'axios';
import statisticsMock from '@/mocks/statistics';

export function fetchStatisticsBreakdown() {
  if (import.meta.env.VITE_USE_MOCK === 'true') {
    return Promise.resolve({ data: statisticsMock });
  }
  return axios.get('/api/statistics/breakdown');
}

这里的细节在于返回结构要和真实axios保持一致，否则调用方拿到response.data会取不到数据。尽量在mock分支里也包一层和真实请求一致的数据结构，不要让上游调用方感知到“这是mock”。

3.4 网络层拦截：MSW把Mock放到更合适的位置

模块级封装虽稳，但有个硬伤：mock逻辑写在业务函数里。但凡哪个组件脑门一热，直接调用fetch('/api/statistics/breakdown')，这个mock就失效了。所以更系统的方案是用MSW（Mock Service Worker），把拦截下沉到浏览器网络层。

MSW的思路是注册一个Service Worker，在真实请求发出前按URL规则返回mock响应。它不侵入业务代码，业务侧只关心“请求接口”，并不知道今天跑的是mock还是真实后端。

js复制// mocks/handlers.js
import { http, HttpResponse } from 'msw';
import statisticsMock from './statistics';

export const handlers = [
  http.get('/api/statistics/breakdown', () => {
    return HttpResponse.json(statisticsMock);
  }),
];

js复制// mocks/browser.js
import { setupWorker } from 'msw/browser';
import { handlers } from './handlers';

export const worker = setupWorker(...handlers);

入口文件按环境变量控制是否启动：

js复制// main.jsx
async function enableMocking() {
  if (import.meta.env.VITE_USE_MOCK !== 'true') return;
  const { worker } = await import('./mocks/browser');
  return worker.start();
}

enableMocking().then(() => {
  createRoot(document.getElementById('root')).render(<App />);
});

选择MSW而不是自己封一层fetch，核心理由有三个：

第一，它更接近真实请求链路。所有业务代码的请求都经过浏览器网络栈，mock的字段、响应头、Status Code都能模拟，连DevTools里看到的请求记录都是完整的，排查问题时不会产生“这个错误到底是不是mock造成的”这种疑问。

第二，它天然支持测试环境。一套handlers可以用在Vitest/Jest的Node环境里，自动化测试也能直接复用mock数据，不走真实网络。

第三，它可以在整个应用范围内生效，但规则是显式的。每个URL都有对应的handler，不会像正则前缀那样误伤其他接口。公共Mock平台地址如果写死在业务代码里，换环境时会痛苦，而MSW只在开发阶段启动，生产模式不会装载worker。

4. 当公共Mock平台开始“飘”，本地Mock服务怎么搭才省心

热搜词里另一个高频问题是“easy mock上不去”。这类公共平台偶尔访问不稳定，我自己也碰到过不止一次。对这种不可控因素，成熟的思路不是找下一个公共平台，而是把核心Mock能力往本地和代码仓库迁移。

4.1 公共Mock平台为什么当不了主力

我不会一竿子打死公共Mock平台。它很适合做一个临时验证，比如你要快速给设计或产品演示一个页面效果，2分钟就能拿到一个可访问的接口。但把它当作前端开发主力依赖，风险会随时间积累：

• 平台的稳定性不受你控制，团队规模越大、请求频率越高，碰到抖动的概率越大。
• mock数据的修改通常发生在网页后台，改完需要手动同步给团队成员。
• mock数据没有版本管理，这次改了，上次是什么没人记得，回溯困难。
• 数据与代码在物理位置上隔离，git提交里看不到mock变更记录，code review形同虚设。

我并不是说公共Mock平台不能用，而是明确它的定位：它是一个“外援”，不是“主力”。主力Mock必须在本地代码仓库里，能随项目一起构建、一起启动、一起审查。

4.2 用Vite插件在开发服务器里挂一个本地Mock中间件

如果你的项目是Vite，加本地mock服务其实非常轻量，不需要单独起一个Node进程，直接在vite.config.js里写一个插件，挂到dev server的中间件上。

js复制// plugins/localMock.js
import type { Plugin } from 'vite';
import statisticsMock from '../mocks/statistics';

export function localMock(): Plugin {
  return {
    name: 'vite-plugin-local-mock',
    apply: 'serve',
    configureServer(server) {
      server.middlewares.use((req, res, next) => {
        if (req.url?.startsWith('/api/statistics/breakdown')) {
          res.setHeader('Content-Type', 'application/json');
          res.end(JSON.stringify(statisticsMock));
          return;
        }
        next();
      });
    },
  };
}

在vite.config.js里注册：

js复制import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { localMock } from './plugins/localMock';

export default defineConfig({
  plugins: [react(), localMock()],
});

这样前端代码本来请求的就是/api/statistics/breakdown，开发环境命中插件规则后直接返回mock数据；一旦后端接口就绪，你只需要把插件从配置里移除，或者按环境变量控制是否启用。业务代码一行都不用改。

用Vite插件的好处在于：mock进程和前端dev server同生共死，不需要额外开终端。如果你用的是其他构建工具，也可以用一个独立的Node服务做同样的事，比如Express:

js复制// mock-server/index.js
const express = require('express');
const statisticsMock = require('../mocks/statistics');
const app = express();

app.get('/api/statistics/breakdown', (_req, res) => {
  res.json(statisticsMock);
});

app.listen(8090, () => {
  console.log('mock server ready at http://localhost:8090');
});

然后在前端配置里把接口代理到8090端口，或直接把请求baseURL指到它。独立进程的好处是跨端复用，后端Java/Go那边的联调环境如果也想用同一套mock数据，也能直接调用。缺点是团队里每个开发者都要记得启动它。

4.3 用环境变量控制“什么时候开mock”，而不是靠注释代码

我翻车那天最大的问题是没有“总开关”。mock逻辑只要写在代码里就会一直生效，除非有人手动删除。正确做法是让mock状态成为环境配置的一部分。

在项目根目录创建.env.development、.env.production，然后：

bash复制# .env.development
VITE_USE_MOCK=true

bash复制# .env.production
VITE_USE_MOCK=false

代码里所有mock相关逻辑都以这个变量为准，生产环境构建时自动不打包mock分支。如果用的是MSW，还要在入口文件里判断：

js复制if (import.meta.env.VITE_USE_MOCK === 'true') {
  // 动态引入，避免打包时把MSW打进生产bundle
  const { worker } = await import('./mocks/browser');
  await worker.start();
}

这里有个关键点是用动态import()，而不是在文件顶部静态import，这样生产环境不会加载sw相关的依赖。即使你在mocks/文件夹里写了很多数据，也能在摇树优化时被剔除。

公共Mock平台不是不能用，但一定要有一条“平台挂了，本地马上能切换”的通道。这条通道不是应急方案，而是日常开发基础设施的一部分。我现在的判断标准很简单：如果一个工具故障会造成前端页面全站不可用，那它就不该被当作“可选的辅助工具”来看待。

5. 从一次白屏事故里拉出来的前端工具链清单

说到底，Mock只是前端开发者工具链的一环。这次翻车让我最受用的不是“以后别用公共平台”这个结论，而是意识到：工具的稳定性，不只是选型的问题，更是使用边界和验证链路的问题。

5.1 别再让页面在异常数据面前“裸奔”

先看最简单也最容易补的一环：UI兜底。统计中心如果当时有一个ErrorBoundary，页面至少不会白屏，会降级成局部报错提示。React类组件两分钟就能写一个：

jsx复制// components/AppBoundary.jsx
import React from 'react';

class AppBoundary extends React.Component {
  state = { hasError: false, errorInfo: null };

  static getDerivedStateFromError(error) {
    return { hasError: true, errorInfo: error };
  }

  componentDidCatch(error) {
    // 这里接前端监控上报
    console.error('渲染异常', error);
  }

  render() {
    if (this.state.hasError) {
      return (
        <div className="error-page">
          <h1>页面开小差了</h1>
          <p>请刷新页面重试，如果持续出现，请联系前端同学。</p>
          <button onClick={() => window.location.reload()}>刷新</button>
        </div>
      );
    }
    return this.props.children;
  }
}

export default AppBoundary;

在路由根节点或需要保护的业务模块外加一层。虽然它不能解决mock数据错误，但它能保证一个模块出问题时不拖垮整个应用。要注意的是，ErrorBoundary只捕获render时期的错误，不捕获事件处理器和异步请求里的错误，所以真正的异步请求还是要靠拦截器或封装统一处理。

5.2 给接口响应加一道运行时“验货”关卡

我在复盘里提到，如果响应数据在入口处被校验过，结构失真根本走不到详情页。前端工程里常见做法是引入Zod这类运行时校验库。

js复制// schemas/statistics.js
import { z } from 'zod';

const BreakdownItemSchema = z.object({
  category: z.string(),
  value: z.number(),
  ratio: z.number(),
});

export const StatisticsBreakdownSchema = z.object({
  code: z.number(),
  message: z.string(),
  data: z.object({
    total: z.number(),
    breakdown: z.array(BreakdownItemSchema),
  }),
});

在请求函数里解析响应：

js复制import { StatisticsBreakdownSchema } from '@/schemas/statistics';

export async function fetchStatisticsBreakdown() {
  const response = await fetch('/api/statistics/breakdown');
  const raw = await response.json();
  // 如果结构不对，zod会在这里抛出详细错误，而不会等到组件render再白屏
  return StatisticsBreakdownSchema.parse(raw);
}

zod.parse失败时会明确指出哪个字段缺失、类型不对，错误信息能直接定位到mock文件或后端接口的问题。它不能替代TypeScript，TypeScript在编译期检查静态类型，Zod在运行时检查真实数据，二者是互补关系。

如果把Zod用到全项目，最开始确实会增加工作量。我的建议是只从核心业务接口开始，尤其是团队内并行开发频繁、接口变更频繁的模块。至少让前端在“结构变化”时能尽早感知，而不是等到页面白屏才排查。

5.3 mock文件也要“入库”和“过审”

这是成本最低、收益最高的一条：把mock文件当作生产代码来管理。我的规矩是，mock文件与业务代码同仓库、同分支、同PR，团队里任何对mock的改动都能在code review里被看到。这样大家会自然地去核对接口文档，而不是随手建一份“能跑就行”的数据。

mock文件可以单独放mocks/目录，也可以在业务模块下建__mock__目录，但要确保一个原则：每个mock文件头注释说明它对应哪个真实接口、哪个版本、创建人是谁。如果后端接口有OpenAPI/Swagger，还可以做一个脚本，自动从接口定义生成基础mock数据，从源头上减少手工造数据结构带来的失真。这个能力如果你的团队没有，值得投入一个下午搭建；有的话，翻车概率又会再降一截。

5.4 公共平台当“外援”，本地/代码内Mock当“主力”

结合前文，我会给一套我自己现在执行的分层策略：

• 场景一：本地开发、代码联调，用Vite插件里的本地mock或MSW，数据来自仓库内mock文件。
• 场景二：自动化测试，直接复用MSW的handlers，跑测试前启动worker，测试结束关闭。
• 场景三：临时给产品/设计演示纯UI效果，可以用公共Mock平台快速造数据，但演示完成后立刻把代码里的地址切回来。
• 场景四：多团队联调，数据要共享，可以把mock数据发布到公司内网的Mock服务，保证稳定与外网隔离，避免把稳定性寄托在外部公共平台上。

一句话：mock不是不允许用，而是要把稳定性掌握在自己可控的版本管理里。

5.5 我从翻车里沉淀出来的几条硬规矩

写到这里，我回想那天深夜，面对满屏pending请求坐在工位上不断刷新页面时的无力感。真正让我后怕的不是公共Mock平台宕机，而是我那时对“浏览器工具/前端工具链”的认知太工具化了：平时觉得用用DevTools、装几个插件、配个热更新就差不多了。可在生产环境里，工具链真正的价值是让你对“可能出问题”的环节提前有感知。那次白屏事故后，我给自己定了几条规矩，如果你也常和Mock打交道，可以直接抄走：

第一，不在组件文件里直接写fetch拦截逻辑。Mock一定要独立成模块或独立插件。第二，mock数据必须与当前接口契约核对一遍，且通过Zod或同类工具做运行时校验。第三，任何Mock方案都要有“总开关”，默认关闭，显式开启。第四，公共Mock平台只能临时使用，主力mock必须本地化、代码化、可review。第五，页面对异常数据要有兜底，ErrorBoundary和空态不是可选优化，是基本功。

顺着这个思路，前端开发者工具就很清楚了：它不只是“能生成假数据”的Mock平台，也不只是DevTools面板。它是一整套让代码在真实世界更不容易崩溃的机制——运行时校验、组件边界、环境控制、版本管理，每一样都是在为“意外”做准备。Mock的意义，在于帮你在依赖不可控时继续前行；而工具的意义，在于让这种前行不用拿线上稳定性冒险。那次白屏虽然狼狈，但我现在反而感激它，因为它用一种尽量小的代价，逼我把这些本该早做的功课补了回来。