使用 Apifox 中的 Mock 数据
开发接口的时候，后端还没写完，前端就要开始联调了。这种情况下，Mock 数据就派上用场了。Apifox 提供了一套完整的 Mock 解决方案，让你可以轻松模拟各种接口响应。
本文我们就来介绍一下 Apifox 的 Mock 功能，从最简单的自动生成到高度自定义的脚本控制，一步步带你掌握这个强大的工具。
智能 Mock：零配置的数据生成
刚接触 Apifox 的时候，你可能会惊讶地发现，就算什么都不配置，接口也能返回合理的 Mock 数据。这就是智能 Mock 的魅力所在。
智能 Mock 会根据你定义的字段类型和名称，自动匹配相应的数据。比如你定义了一个 name 字段，类型是 string，Apifox 就知道这里应该生成一个人名；如果是 email 字段，就会生成邮箱地址；phone 字段就生成电话号码。
这背后其实是 Apifox 内置的一系列匹配规则在起作用。当你的字段类型和名称符合某个规则时，系统就会按照对应的规则生成数据。这意味着你只需要按照常见的命名规范来定义字段，就能得到相当真实的测试数据。这些个规则你可以在项目设置里面编辑。
不过智能 Mock 虽然方便，但毕竟是通用的规则，有时候可能不太符合你的具体需求。这时候就需要更精细的控制了。
自定义 Mock：精确控制数据格式
当智能 Mock 生成的数据不够精确时，你可以通过 Mock 表达式来限定值的范围和格式。Apifox 的动态值功能基于 Faker.js 库，提供了丰富的数据生成方法。
使用语法很简单：{{$分类.方法}}。比如你想生成一个中文姓名，就用 {{$name.fullName}}；想要一个手机号码，就用 {{$phone.mobile}}；需要一个日期，可以用 {{$date.now}}。这些自定义的动态值表达式（Mock 表达式）不用记的，直接在“数据生成器”里选就行了，还支持搜索。
这些表达式不仅可以用在响应数据中，还能用在请求参数里。比如你在测试一个用户注册接口，可以在请求体中使用这些动态值，每次发送请求都会生成不同的测试数据。
自定义 Mock 让你在保持数据真实性的同时，又能精确控制数据的格式和类型。但如果你需要更复杂的逻辑控制，比如根据不同的条件返回不同的响应，那就需要用到 Mock 期望了。
Mock 期望：条件化的响应控制
Mock 期望是 Apifox 提供的高度自定义功能，让你能够完全控制 Mock 服务返回的内容。这个功能特别适合模拟复杂的业务场景。
比如你有一个用户查询接口，需要根据不同的用户 ID 返回不同的响应。普通用户返回基本信息，VIP 用户返回详细信息，不存在的用户返回 404 错误。这种情况下，智能 Mock 和自定义 Mock 都无法满足需求，因为它们不能根据请求内容来决定响应内容。
Mock 期望就是为了解决这类问题而设计的。你可以设置多个期望规则，每个规则对应不同的请求条件和响应内容。当收到请求时，Apifox 会按照你设置的条件来匹配相应的期望，返回对应的响应数据。
这样一来，你就能模拟出非常真实的接口行为，包括各种边界情况和异常场景。但有时候，即使是 Mock 期望也不够灵活，你可能需要编写一些逻辑来处理更复杂的场景。
Mock 脚本：终极的自定义能力
当前面几种方式都无法满足你的需求时，Mock 脚本就是最后的大招了。通过编写 JavaScript 代码，你可以实现任何复杂的 Mock 逻辑。
Mock 脚本的工作原理其实很直观。首先，系统会使用智能 Mock 或其他 Mock 功能生成一个初始的响应数据。然后你的脚本开始执行，可以通过 $$.mockRequest 对象访问请求信息，通过 $$.mockResponse 对象访问初始响应。
在脚本中，你可以读取请求参数，进行各种计算和判断，然后生成你需要的响应数据。最后使用 $$.mockResponse.setBody 方法，将处理后的数据设置为最终的响应内容。
比如你可以写一个脚本，根据请求中的分页参数计算出正确的数据条数，或者根据用户权限返回不同的字段，甚至可以模拟一些随机的网络延迟和错误。
// 获取自动 Mock 出来的数据
var responseJson = $$.mockResponse.json();
// 修改 responseJson 里的分页数据
// 将 page 设置为请求参数的 page
responseJson.page = $$.mockRequest.getParam("page");
// 将 total 设置 120
responseJson.total = 120;
// 将修改后的 json 写入 $$.mockResponse
$$.mockResponse.setBody(responseJson);
Mock 脚本给了你定义响应数据控制权，但同时也需要你具备一定的编程能力。不过对于大多数场景，前面几种方式已经足够用了。需要注意的是，Mock 脚本不能使用变量，不提供日志功能，不能使用 pm 对象，前置操作和后置操作的脚本语法不能在 Mock 脚本里使用。
Mock 服务器：让 Mock 数据跑起来
说了这么多生成 Mock 数据的方式，那这些数据是怎么提供给客户端的呢？这就涉及到 Mock 服务器了。
Apifox 提供了三种 Mock 服务器：本地 Mock、云端 Mock 和自托管 Runner Mock。它们的关系是这样的：无论你用的是智能 Mock、自定义 Mock、Mock 期望还是 Mock 脚本，最终都需要通过这三种服务器之一来提供服务。
本地 Mock 是最简单的方式，它运行在你的 Apifox 客户端上。当你在 Apifox 中定义好接口和 Mock 规则后，本地就会启动一个 Mock 服务器，其他应用可以通过 HTTP 请求来获取 Mock 数据。这种方式的好处是完全私有，不需要网络连接，但缺点是只有你本地能访问。发送接口请求的时候在右上角的“环境管理”中切换到本地 Mock 即可。
云端 Mock 则是运行在 Apifox 的云服务器上。你定义的 Mock 规则会同步到云端，任何人都可以通过云端地址来访问这些 Mock 数据。这对于团队协作特别有用，前端开发者可以直接使用云端的 Mock 地址来协作开发。
自托管 Runner Mock 是最灵活的选择，它让你可以在自己的服务器上运行 Mock 服务。这样既保证了数据的私密性，又能让团队成员共享 Mock 数据。对于有严格安全要求的企业来说，这是最理想的选择。在使用 Runner Mock 之前需要在服务器上部署，具体方法参考帮助文档的自托管 Runner Mock 章节。
三种服务器的核心功能是一样的，都能执行你定义的各种 Mock 规则。选择哪种主要看你的使用场景：个人开发用本地 Mock，团队协作用云端 Mock，企业级应用用自托管 Runner Mock。
现在你应该对 Apifox 的 Mock 体系有了完整的认识。从简单的智能 Mock 开始，到自定义表达式，再到复杂的期望规则和脚本控制，最后通过不同的服务器形式对外提供服务。这套完整的方案能够满足从简单到复杂的各种 Mock 需求，让你在接口开发过程中游刃有余。
