理解 Mock 的本质，是打破前后端联调壁垒的第一步

前言：一个常见的团队协作困境

在日常开发协作中，前端与后端常常面临以下尴尬局面：

• 前端同学页面写完了，但后端接口还在开发中，只能干等，或者手动写死data: []来占位。

• 后端同学负责的微服务依赖第三方支付网关或复杂的数据库状态，本地测试时既不可能真实扣费，也不可能随时造出“余额不足”的异常场景。

• 写单元测试时，测试代码一跑就去请求真实数据库，不仅慢，而且每次跑完数据都变了，测试结果不稳定。

这种“干等”“不敢测”“测不准”的僵局，正是Mock技术大显身手的地方。然而不少新手误以为 Mock 就是Mock.js造几个假名字，这仅仅是冰山一角。

本文将从全栈视角出发：首先说清楚 Mock 是什么、为什么用，然后横向对比前后端 Mock 的本质差异与各自工具链，再纵向落地到Vue 3 + Vite项目中进行实战演练，最后补充后端的 Mock 示例作为扩展阅读。读完这篇，应能独立完成前端联调，也能看懂后端同事写的@Mock单元测试代码。

一、什么是 Mock？（全栈通用定义）

1.1 官方定义

在软件工程中，模拟对象（Mock Object）是以可控的方式模拟真实对象行为的假的对象。它充当复杂、不可用或不可预测的依赖项（如数据库、API 或外部服务）的替代品。

通俗来说：用一个“替身”代替真实的依赖组件，让开发者能专心测试自己的业务逻辑，而不用担心那些外部依赖的问题。

1.2 经典比喻：碰撞测试假人

这个比喻来自维基百科：程序员创造模拟对象来测试其他对象的行为，很类似汽车设计者使用碰撞测试假人来模拟车辆碰撞中人的动态行为。

• 汽车设计师不可能每次都找真人去撞车——成本太高、不安全、不可控。

• 软件开发者不可能每次都去请求真实数据库或调用真实支付接口——太慢、不稳定、有副作用。

碰撞测试假人就是真实人体的“Mock 对象”，而模拟对象就是真实依赖的“Mock 对象”。两者的本质一致：用一个安全、可控的替身，替代真实但危险、不可控的实体。

1.3 什么时候需要 Mock？

根据维基百科的总结，以下情形可能需要使用模拟对象来代替真实对象：

1. 真实对象的行为不确定（例如当前时间、当前温度、随机数）。

2. 真实对象很难搭建（例如需要复杂的容器环境才能构造的HttpServletRequest对象）。

3. 真实对象的行为很难触发（例如网络超时、数据库连接失败等异常场景）。

4. 真实对象速度很慢（例如完整的数据库，测试之前可能需要初始化大量数据）。

5. 真实对象可能还不存在（例如后端接口尚未开发完成）。

6. 真实对象包含不适合测试的信息或方法（例如会产生真实扣费或发送真实邮件）。

总结：只要某个依赖让测试变慢、变难、变不稳定，或者根本还不存在，就可以考虑用 Mock 替换它。

二、为什么需要 Mock？（四大核心价值）

2.1 隔离测试，精准定位 Bug

假设要测试一个“下单”功能。真实代码同时调用了数据库、风控系统和物流 API。一旦报错，很难判断是哪个环节出了问题。

用 Mock 把周边依赖全替换掉，只测试“下单”逻辑本身。哪里出问题，一目了然。

2.2 消除不确定性，让测试稳定

真实环境下，支付接口可能网络超时，数据库可能偶尔报错。用 Mock 可以固定返回“成功”或“失败”的预设结果，让测试结果不再随外部环境波动——今天跑是绿的，明天跑还是绿的。

2.3 模拟极端情况，兜底测试

真实的数据库很难触发“磁盘满了”或“连接超时”这种罕见异常。但用 Mock，可以轻松模拟这些极端情况，验证自己的代码在异常发生时会不会崩溃。

2.4 解耦团队，并行开发

在前后端分离的开发模式下，Mock 数据是并行开发的基础设施。前端不需要等后端接口写好再开工，后端也不需要等前端页面做好再调试接口。各自用 Mock 把对方“替”掉，并行推进。

三、核心概念：测试替身（Test Double）大家族

在深入前后端对比之前，有必要先了解一个更大的概念框架——测试替身（Test Double）。

“Test Double”这个词由 Martin Fowler 提出，类比电影中的“特技替身”（Stunt Double）。在测试中，我们用各种“替身”来替代真实对象。Mock 只是其中一种。根据 Martin Fowler 和业界共识，测试替身主要分为以下五类：

Mock 与 Stub 的核心区别（这也是不少新手容易混淆的地方）：

• Stub（桩）：只负责“回话”。你给我什么输入，我死板地返回预设输出。不关心你调没调、调了几次。

• Mock（模拟）：不仅回话，还“记账”。它会验证“这个函数到底被调用了没？调用了几次？传参对不对？”——它会验证行为。

用大白话总结：Stub 是“你说什么我答什么”，Mock 是“我不仅要答，还要检查你是不是按规矩问的”。

四、核心对比：前端 Mock vs 后端 Mock（全栈对照表）

不少前端同学在阅读后端测试代码时，会对when().thenReturn()和verify()感到陌生。下面这张表格从替身对象、核心目的、触发时机、主流工具、关注点五个维度厘清了前后端 Mock 的差异：

举个例子，秒懂差异：

• 前端 Mock 场景：后端接口还没部署，前端用 Mock 返回{ code: 0, data: { name: "张三" } }。前端关心的是“张三”这两个字在页面上显示得是否美观、有没有溢出、空状态图是否正常显示”。

• 后端 Mock 场景：后端要测试UserService.getUserById(1)这个方法。但getUserById内部调了UserMapper.selectOne(1)去查真实数据库。测试时用 Mockito 把UserMapper替换掉，设定when(selectOne(1)).thenReturn(mockUser)。后端关心的是“当 Mapper 返回 mockUser 后，Service 层是否正确地给这个用户加了 VIP 等级标记”。

五、全栈通用准则：边界隔离原则

在编写任何 Mock 代码前，有一条需要牢记的原则：

只 Mock 外部边界，不 Mock 内部核心业务逻辑。

• 外部边界：HTTP API、数据库连接、文件 I/O、第三方支付网关、消息队列。这些资源不受开发者控制，且极易产生副作用（如真实扣费），应通过 Mock 隔离。

• 内部核心：自己编写的纯函数（如金额计算器、权限校验器、数据格式化函数）。不建议 Mock 这些逻辑，应使用真实代码执行，否则测试将失去意义——跑过了也不代表真实逻辑没问题。

后果警示：如果把内部核心逻辑也 Mock 掉，测试就会变成“自欺欺人的绿色假象”——测试全绿，上线全崩。

六、前端实战（一）：Vue 3 + Vite 项目中的 Mock 落地（vite-plugin-mock）

现在进入实战环节。在 Vue 3 官方标配的 Vite 构建工具下，vite-plugin-mock是目前侵入性较低、配置较简单的解决方案之一。

它的一大优势是零污染业务代码：开发者无需将axios.get('/api')修改为其他地址，插件会在开发服务器层面自动拦截匹配的请求。

6.1 安装依赖

bash

npm install vite-plugin-mock mockjs -D

注释：-D表示--save-dev，即仅安装在开发依赖中，不会被打包到生产环境。mockjs用于生成随机数据（如随机姓名、图片、邮箱），vite-plugin-mock则是 Vite 的插件，负责拦截请求并返回模拟数据。

6.2 配置vite.config.ts

typescript

import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' import { viteMockServe } from 'vite-plugin-mock' export default defineConfig(({ command }) => ({ plugins: [ vue(), viteMockServe({ mockPath: 'mock', // 约定根目录下的 mock 文件夹存放源码 enable: command === 'serve', // 只有开发环境（npm run dev）才开启 mock buildEnable: false, // 构建时强制关闭，双重保险 watchFiles: true, // 监听 mock 文件变化 logger: true, // 在控制台显示请求日志 }), ], }))

注释：command === 'serve'是 Vite 提供的环境判断方式——npm run dev时command为'serve'，npm run build时为'build'。buildEnable: false作为第二道保险，确保 Mock 不会被意外打包到生产代码中。

6.3 在根目录编写mock/user.ts接口定义

在项目根目录（不是src里）新建文件夹mock，在里面新建user.ts：

typescript

import { MockMethod } from 'vite-plugin-mock' import Mock from 'mockjs' export default [ { url: '/api/user/info', method: 'get', response: () => ({ code: 0, data: Mock.mock({ 'name': '@cname', // 生成随机中文姓名 'avatar': '@image(100x100)', // 生成随机图片 URL 'email': '@email', // 生成随机邮箱 'date': '@date', // 生成随机日期 }), }), }, { url: '/api/user/login', method: 'post', response: ({ body }) => { // 可以根据请求体中的参数返回不同数据，模拟真实接口的逻辑分支 if (body.username === 'admin') { return { code: 0, token: 'mock-jwt-token' } } return { code: -1, message: '认证失败，请检查用户名' } }, }, ] as MockMethod[]

注释：

• @cname、@image、@email、@date是 Mock.js 的数据占位符（Data Placeholder Definition，DPD），用于生成各种格式的随机数据。

• 'name': '@cname'这种属性名: 占位符的写法属于数据模板定义规范（Data Template Definition，DTD）。

6.4 Vue 组件中的调用

vue

<template> <div> <p>用户名：{{ userInfo.name }}</p> <img :src="userInfo.avatar" alt="头像" /> <p>邮箱：{{ userInfo.email }}</p> </div> </template> <script setup lang="ts"> import { ref, onMounted } from 'vue' import axios from 'axios' // 使用 ref 包裹数据，保持 Vue 的响应式 const userInfo = ref({}) onMounted(async () => { // 直接请求真实生产环境预期的地址即可 // vite-plugin-mock 在开发层自动拦截，业务代码不用改 const { data } = await axios.get('/api/user/info') if (data.code === 0) { userInfo.value = data.data } }) </script>

注释：这里使用ref包裹数据是因为 Vue 的响应式系统要求：只有被ref或reactive包裹的数据，模板才能感知到变化并重新渲染。如果直接写let userInfo = {}，数据变化了页面也不会更新。

6.5 验证效果

启动项目：

bash

npm run dev

打开浏览器 F12 查看 Network 面板，会发现请求状态是200，返回的数据正是 Mock 定义的假数据。vite-plugin-mock的一个特点是网络控制台会正常显示模拟的网络请求，而传统的Mock.js直接拦截 Ajax 时控制台不会有任何请求记录。

七、前端实战（二）：进阶方案 —— MSW（Mock Service Worker）

如果项目对 Mock 方案的专业性、可复用性、跨环境能力有更高要求，可以了解一下MSW（Mock Service Worker）——目前前端社区认可度较高的方案之一。

7.1 什么是 MSW？

MSW 是一个用于浏览器和 Node.js 的 API Mock 库。它通过在浏览器中注册一个 Service Worker，在网络层面拦截请求。

注释：Service Worker 是浏览器的一个底层 API，原本用于实现离线缓存和推送通知等功能。MSW 利用它来拦截网络请求。

7.2 MSW 的主要特点

1. 环境无关：不依赖任何框架或请求库。无论用原生fetch、Axios、React Query 还是 Apollo，MSW 都能拦截。

2. 网络级拦截：不篡改fetch或XMLHttpRequest的原生方法，而是利用浏览器标准 API 在网络层拦截真实请求。

3. 可复用：同一套 Mock 代码可以在开发、集成测试、端到端测试（E2E）、Storybook 中复用。

7.3 MSW 与 vite-plugin-mock 的对比

建议：新手可以先从vite-plugin-mock入手；项目规模扩大后，可考虑迁移到 MSW。

八、扩展视野：后端 Mock 长什么样？（以 Java Mockito 为例）

为了建立全栈认知，这里展示一段 Java 生态中使用Mockito框架的单元测试代码。即使没学过 Java，通过注释也能理解其逻辑。

8.1 什么是 Mockito？

Mockito 是 Java 世界中主流的 Mock 框架之一。它允许开发者创建和配置 Mock 对象，并验证这些对象上的交互行为。

8.2 代码示例

java

// 导入 Mockito 的静态方法，让代码更简洁 import static org.mockito.Mockito.*; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.extension.ExtendWith; import org.mockito.InjectMocks; import org.mockito.Mock; import org.mockito.junit.jupiter.MockitoExtension; @ExtendWith(MockitoExtension.class) // 启用 Mockito 的 JUnit 支持 public class UserServiceTest { // @Mock：创建一个替身，用于模拟数据库 Mapper（不会真的去连库） @Mock private UserMapper userMapper; // @InjectMocks：将上面的 Mock 对象注入到真实的业务 Service 中 @InjectMocks private UserService userService; @Test void testCalculateVipLevel() { // 1. 构造假数据 User mockUser = new User(); mockUser.setId(1L); mockUser.setScore(85); // 2. 设定替身行为：当调用 selectById(1L) 时，返回上面造好的假对象 // 这就是“打桩（Stubbing）” when(userMapper.selectById(1L)).thenReturn(mockUser); // 3. 执行真实业务逻辑（这里应跑真正的代码，不应用 Mock） // 这就是“边界隔离原则”——只 Mock 外部依赖，不 Mock 内部逻辑 Integer vipLevel = userService.calculateVipLevel(1L); // 4. 断言（Assert）：85 分预期返回 VIP 等级 3 assertEquals(Integer.valueOf(3), vipLevel); // 5. 行为验证（Verify）：确保 Mapper 确实被调用且仅调用了 1 次 // 这就是 Mock 区别于 Stub 的核心——验证交互行为 verify(userMapper, times(1)).selectById(1L); } }

8.3 关键点解读

• @Mock：创建一个模拟对象，不执行真实代码。

• when(...).thenReturn(...)：设定模拟对象的行为——当某个方法被调用时，返回什么值。

• verify(...)：验证模拟对象的方法是否按预期被调用——调用了没？调了几次？参数对不对？

• @InjectMocks：将 Mock 对象注入到被测试的业务类中。

后端 Mock 的一个核心关注点是验证行为（verify），它关心“这个方法到底被执行了几次，参数传对了没有”——这是前端 Mock 工具链中较少涉及但同样重要的概念。

九、避坑指南：生产环境安全的 4 条注意事项

为确保 Mock 机制不会引发线上事故，以下四条值得关注：

9.1 环境隔离

• 前端：确认buildEnable: false或使用command === 'serve'条件守卫，防止 Mock 拦截器被打包进dist产物。

• 后端：确认测试依赖的 Scope 限定为test（如 Maven 的<scope>test</scope>），防止 Mock 框架被传递至生产 Classpath。

• 后果：一旦 Mock 逻辑混入生产环境，将导致前端请求永远返回假数据，或后端直接抛出ClassNotFoundException引发启动失败。

9.2 数据仿真度

• 前端场景中，建议利用@cname、@email、@image等占位符生成符合真实格式的数据，而非简单的"测试1"、"测试2"。否则当真实接口上线时，可能因真实数据长度、格式异常而引发布局错乱。

• 后端场景中，Mock 对象需完整填充关键字段（如 null 值判断分支），避免因遗漏属性导致测试通过但线上空指针。

9.3 修改 Mock 定义后需重启进程

• 无论是 Vite 插件还是 Maven Surefire 插件，均在进程启动时完成文件扫描与路由注册。修改mock目录或测试类源码后，建议重启npm run dev或重新执行mvn test以确保变更生效。

9.4 避免过度 Mock

• 只 Mock 外部边界（API、数据库、文件系统），不 Mock 内部核心逻辑。

• 如果一段代码的依赖过于复杂以至于难以 Mock，往往意味着需要重新审视代码的架构设计——耦合度可能偏高。

十、总结

Mock 不仅是前端“等接口”时的权宜之计，也可以作为衡量系统架构解耦程度的一个参考。若一个模块的依赖过于复杂以至于难以 Mock，往往意味着需要重新审视其设计合理性。

希望本文能帮助读者建立一个跨越前后端技术栈的统一 Mock 认知体系。如有收获，欢迎收藏、点赞、转发。