原文链接：Mock方案对比

在真实工作环境中，由于后端与前端并行开发，所以在前期是没有后端接口可以使用的，因而选择最适合自己的 Mock 数据的方法就非常重要。

此处对比下业界常见的 Mock 方案，选择并配置其中最合适的方案。

方案一、代码侵入

在代码中写死 Mock 数据，或者请求本地的 JSON 文件。

优点：无
缺点：

  • 和其他方案比 Mock 效果不好；
  • 与真实 Server 环境的切换非常麻烦，一切需要侵入代码切换环境的行为都是不好的；

方案二、请求拦截

代表：Mock.js

示例：

  1. Mock.mock(/\\/api\\/visitor\\/list/, 'get', {
  2.   code: 2000,
  3.   msg: 'ok',
  4.   'data|10': [
  5.     {
  6.       'id|+1': 6,
  7.       'name': '@csentence(5)',
  8.       'tag': '@integer(6, 9)-@integer(10, 14)岁 @cword("零有", 1)基础',
  9.       'lesson_image': "<https://images.pexels.com/3737094/pexels-photo-3737094.jpeg>",
  10.       'lesson_package': 'L1基础指令课',
  11.       'done': '@integer(10000, 99999)',
  12.     }
  13.   ]
  14. })

优点：

  1. 与前端代码分离；
  2. 可生成随机数据；

缺点：

  1. 数据都是动态生成的假数据，无法真实模拟增删改查的情况。
  2. 只支持 ajax，不支持 fetch。

方案三、接口管理工具

代表：rap、swagger、moco、yapi

优点：

  1. 配置功能强大，接口管理与 Mock 一体，后端修改接口 Mock 也跟着更改，可靠。

缺点：

  1. 配置复杂，依赖后端，可能会出现后端不愿意出手，或者等配置完了，接口也开发出来了的情况。
  2. 一般会作为大团队的基础建设而存在， 没有这个条件的话慎重考虑。

方案四、本地 node 服务器

代表：json-server

优点：

  1. 配置简单，json-server 甚至可以 0 代码 30 秒启动一个 REST API Server；
  2. 自定义程度高，一切尽在掌控中；
  3. 增删改查真实模拟；

缺点：

  1. 与接口管理工具相比，无法随着后端 API 的修改而自动修改。