全栈视角下的 Mock 指南：从后端单元测试到前端 Vue 3 联调

理解 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 和业界共识，测试替身主要分为以下五类：

类型	英文	核心特征	使用场景
虚设对象	Dummy	仅用于填充参数，从未被真正使用	满足方法签名要求，但测试中不关心它
伪对象	Fake	有真实工作实现的简化版本（如内存数据库）	集成测试，需要真实但轻量的行为
桩对象	Stub	提供预设的"罐头回答"，不关心被调用了几次	需要可控的返回值，但不验证调用行为
间谍对象	Spy	包装真实对象，记录调用信息供事后验证	需要部分真实行为，同时记录调用
模拟对象	Mock	预设期望，验证是否按预期被调用	需要验证交互行为是否正确

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

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

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

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

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

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

对比维度	前端 Mock	后端 Mock
替身对象	浏览器的 XMLHttpRequest / fetch 请求、第三方 JS-SDK（如微信 JSSDK）、LocalStorage / SessionStorage	数据库 DAO/Repository 层、Redis 缓存、消息队列（MQ）、第三方 HTTP 客户端（如 OkHttp）、文件系统
核心目的	解耦 UI 渲染与后端 API ：在无真实数据时构建页面；重点模拟 Loading、空状态、超长文本溢出等视觉边界条件	解耦业务逻辑与基础设施 ：在单元测试中不依赖真实数据库和网络，重点验证数据计算与流转的正确性
触发阶段	开发联调阶段（npm run dev）、视觉回归测试	后端构建阶段（mvn test / gradle test）、持续集成（CI）流水线
主流工具	Mock.js、MSW（Mock Service Worker）、vite-plugin-mock、Jest / Vitest	Java 生态：Mockito / PowerMock；Go 生态：gomock；Python：unittest.mock
核心关注点	响应数据字段名和类型是否匹配、UI 样式是否因数据长度异常而错乱	方法调用次数 （verify）、入参匹配规则 （anyString()）、预期异常类型是否正确抛出

举个例子，秒懂差异：

• 前端 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
实现方式	基于 Vite 开发服务器的中间件拦截	基于 Service Worker 浏览器底层 API 拦截
环境支持	仅限 Vite 开发环境	浏览器 + Node.js
代码复用性	仅开发环境可用	开发、测试均可复用
学习成本	较低，配置简单	中等，需理解 Service Worker 概念
适用场景	中小型项目、快速原型	大型项目、需要 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 vs Stub	Stub 提供预设回答，Mock 还要验证交互行为
前端 Mock	解耦 UI 与后端，关注视觉边界和字段格式
后端 Mock	解耦业务与基础设施，关注调用次数和异常处理
边界原则	只 Mock 外部边界，不 Mock 内部核心逻辑
环境隔离	Mock 代码应限制在开发/测试环境，不上线

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

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