Apifox如何托管可共享的云端Mock服务端教程

时间：2026-08-15 13:27

你的前端团队开发进度卡住了。设计稿已经确认，页面也完成了一半，当前唯一拖慢排期的，往往就是某个尚未上线的 API 接口。后端研发还要再经历一个迭代周期才能交付，因此 UI 暂时没有真实接口可用。很多团队会先用本地 mock 顶上，但问题在于：当你关掉电脑，本地 mock 也会随之失效。紧接着，身处不

你的前端团队开发进度卡住了。设计稿已经确认，页面也完成了一半，当前唯一拖慢排期的，往往就是某个尚未上线的 API 接口。后端研发还要再经历一个迭代周期才能交付，因此 UI 暂时没有真实接口可用。很多团队会先用本地 mock 顶上，但问题在于：当你关掉电脑，本地 mock 也会随之失效。紧接着，身处不同时区的同事一旦继续联调，这个接口就会直接不可用。

这正是 Apifox 云端 mock 重点解决的场景。与只在单台电脑上临时运行的本地 mock 不同，Apifox 可以提供一个托管在 mock.apifox.com 上的公共 URL，并保持持续在线。即使后端还没开始写代码，前端、QA 测试人员以及合作方开发者也能立即调用这些接近真实返回结果的接口。如果你想先系统了解 mock 对团队协作的价值，可以先阅读关于 API mock 是什么以及适用场景的入门内容。至于公共 mock URL 在请求链路中的工作方式，HTTP 请求/响应模型的 MDN 参考资料也值得顺手复习。

什么是云端 mock，以及为什么本地 mock 远远不够

Apifox 会为你定义的每一个 API 自动生成对应的 mock 接口。默认情况下，它采用的是本地 mock：也就是运行在你的 Apifox 实例中，并且只有在你的设备开机时才能正常返回响应。一旦电脑关闭，这个接口也就无法继续访问。对于个人调试来说，这没有太大问题；但只要团队里的其他成员依赖这个 URL，它就会立刻成为协作瓶颈。

云端 mock 正是为此而生。它是一种持续在线、独立于单台设备存在的 mock 接口服务。无论同事的电脑是否休眠，或者你的笔记本是否已经合上收起，云端 mock 都会 7x24 小时稳定响应请求。因为该接口托管在 Apifox 的云服务中，所以它的可用性不取决于某个人是否在线。

它带来的直接收益，就是让跨团队交接变得更顺畅。你先定义好 API 契约，开启云端 mock，再把可访问的 URL 分享出去。前端可以基于接近真实的数据提前开发页面，QA 能依据真实响应结构编写测试用例，外部合作伙伴也能马上开始接入自己的客户端。大家无需等待后端开发完成，也不需要依赖你手动维持服务在线。如果你的项目涉及跨地域协作，那么共享 mock 服务端与环境的方式，会更完整地体现这种工作流优势。

启用云端 mock 并获取你的公共 URL

下面用一个实际 API 场景来说明。假设你正在开发一个 users 服务，其中包含一个返回客户记录列表的 GET /users 接口。你可以按照以下方式，把它转换成一个可共享的云端 mock 接口。

步骤 1：开启云端 mock

打开你的项目，进入项目设置 > 功能设置 > Mock 设置，然后打开云端 Mock 开关。该设置会通知 Apifox 将 mock 接口托管到持续运行的云端服务，而不只是仅在本地环境中提供访问。

每个项目通常只需要设置一次。启用之后，项目中的每一个接口除了原有的本地 URL 之外，还会额外获得一个云端 mock URL。

要为你的项目启用云端 Mock，需要：

1.在项目中打开 “项目设置”

2.选择 “功能设置 -> Mock 设置”

3.启用 “云端 Mock”

如何使用 Apifox 托管可共享的云端 Mock 服务端

或者在 form-data 或 x-www-form-urlencoded 请求中，以名为 apifoxToken 的 body parameter 进行传递，这种方式更适合发送表单 body 的客户端。

对于前端项目代码来说，使用 header 传递通常更清晰也更安全。这样可以避免 Token 出现在会记录完整 URL 的日志中，同时也能把凭证信息与资源路径分离：

ja vascript const res = await fetch( "https://mock.apifox.com/m1/2689726-0-default/users", { headers: { apifoxToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi" } } ); const users = await res.json();

这里有一个需要提前考虑的点：如果你是在已经把普通 URL 分享给调用方之后，才启用 Token 鉴权，那么所有接入方都必须补充这个 Token，否则请求将全部失败。建议提前同步切换计划，避免 QA、前端或合作方因为接口突然被拒绝而影响联调进度。

使用本地化（locales）生成符合特定区域的真实数据

如果一个 mock 接口对每条记录都只返回 "name": "string"，那它对 UI 测试的帮助其实非常有限。相反，如果 mock 能返回真实感更强的姓名、地址和电话号码，前端就能在真实后端接入前，更早发现布局错位、文本溢出、字段格式异常等问题。Apifox 底层通过 Faker.js 实现这类数据生成，而 locale 本地化控制对于国际化产品尤其重要。

默认本地化（locale）的工作原理

默认情况下，Faker 会遵循项目的语言设置。你可以在项目设置 > 基本设置中进行配置，所选择的语言会成为所有生成 mock 数据的默认 locale。比如把项目语言设置为法语，那么生成出来的姓名和地址也会更接近法国地区的风格，无需为每个字段单独处理。

为整个项目重写本地化（locale）设置

如果你希望 mock 数据使用与项目语言不同的特定 locale，也可以单独覆盖。进入项目设置 > 功能设置 > Mock 设置，然后在下拉选项中选择一个 Faker locale。这个项目级覆盖的优先级高于“基本设置”中的默认项目语言，并会应用到项目内的所有相关字段。

这在做国际化界面验证时非常实用。比如把项目 locale 调整为日本，那么所有生成的地址、姓名和电话号码都会体现当地特征，便于你检查 UI 在非拉丁字符、特殊姓名格式以及不同地址结构下的展示效果。基于数据模型自动生成这类 schema-aware 的真实数据，本身也是智能 mock 的重要价值之一。关于 Apifox 智能 mock 如何读取数据模型并完成生成，还有更深入的说明可供参考。

按字段重写本地化（locale）设置

有时，你可能只希望某一个字段使用与其他字段不同的 locale，比如构造一个包含多个地区用户的客户列表。此时可以直接在 mock 表达式中通过 locale parameter 指定本地化：

这样一来，只有这个字段会输出类似 田中太郎 的日语姓名，而响应中其他字段仍然沿用项目默认的 locale 配置。其优先级关系为：字段级 locale 高于项目级 locale，项目级 locale 又高于“基本设置”中的默认语言。因此，你可以先设置一个合理的项目默认值，再只对确有需求的字段做精细化覆盖。

顺便补充一点范围说明：文档中以 ja 作为示例，但并没有完整列出所有支持的 locale 代码。因此在正式落地前，建议先到 Apifox mock 文档中核对目标国家或地区的具体代码。Faker 自身的标准说明，则可以在 Faker.js locale 参考中查看。

同时匹配时区

时间字段也支持类似的控制方式。项目级默认值位于项目设置 > 功能设置 > Mock 设置中，同时你也可以在 mock 表达式里通过 timeZone parameter 对单个字段进行覆盖。如果你的前端页面需要展示时间戳，这项设置可以确保生成的 createdAt 与目标区域时区一致，而不是沿用服务端所在地区的默认时间。

通过 locale 与时区的组合控制，你可以基于同一份接口数据模型，生成逼近日本用户、德国用户，甚至混合国际化用户群体的 mock 数据。至于它还能衍生出哪些更广泛的业务场景，也很值得进一步看看实用的 API mock 应用案例汇总。

Cloud Mock 对比自托管 mock

Cloud Mock 是 Apifox 提供的托管式方案，适合绝大多数研发团队。如果你的组织对数据驻留有严格要求，或者明确规定测试流量不能经过第三方云平台，Apifox 也支持在自有基础设施中部署 mock 服务。这个取舍其实很清晰：云端 mock 的优势是开箱即用、无需额外运维，并且始终在线；自托管 mock 的优势则是完全可控，但你需要自己承担部署和维护成本。如果你的团队更适合后者，可以进一步参考 Apifox mock 服务端自托管的相关指南。对于还在评估不同部署方式的团队，在线 API mock 工具的对比分析也有助于快速了解整体市场格局。

另外，关于版本方案限制，这里有必要说得更明确一些：文中提到的 Cloud Mock 和 locale 功能，并没有清楚标注其对应的版本权限或套餐要求。相比直接依据博客描述做判断，更稳妥的做法还是登录自己的账户，实际确认当前工作区到底开放了哪些能力。你也可以下载 Apifox，完整跑一遍端到端流程，顺便核实自己当前可用的具体功能。

使用 Apifox CLI 自动执行工作流

Apifox 的 mock 能力本质上属于 GUI 与云端托管能力。mock 响应是基于你定义的接口数据模型自动生成的，并由 Apifox 的托管引擎负责对外提供服务，而不是依赖你在终端里启动某个本地程序。所以需要明确一点：Apifox CLI 本身不会启动或运行 mock 服务端。它的价值在于帮助你持续维护 mock 所依赖的输入数据准确性。

CLI 配合 Cursor、Claude Code 等 AI 编程 Agent，可以用于创建或更新项目中的接口定义和数据模型。由于云端 mock 是读取这些数据模型来生成响应数据的，因此只要接口定义保持最新，mock 输出也会随着 API 演进而同步更新。当你用 Agent 工具新增字段时，mock 结果通常也会自动体现对应变化，无需再手动编辑响应内容。

进一步来说，当 mock 已经帮助前端解除开发阻塞，真实后端也开发完成之后，同一项目中的测试场景就可以在无头（headless）模式下执行。CLI 的运行命令能够基于 mock 所描述的同一份 API 契约，去校验实际运行中的后端服务：

apifox run -t -e -r cli

这条命令会在指定环境下执行已保存的测试场景并输出结果，从而让前期用于打通 UI 开发的 mock，与后期验证真实后端的自动化测试，都建立在同一个单一可信源之上。你可以直接在 Apifox 中打开对应场景，复制系统自动生成、已填充好 -t 场景 ID 和 -e 环境 ID 的命令，无需手动拼接参数。如果你还希望把这套流程接入自动化流水线，可以继续参考在 CI/CD 流水线中运行 Apifox 的实践指南。

FAQ

关闭 Apifox 后，云端 mock URL 还能继续使用吗？

可以，这正是云端 mock（Cloud Mock）的核心价值。与依赖宿主机在线的本地 mock 不同，云端 mock 由 Apifox 的云基础设施持续提供服务，并保持 24/7 全天候可用。无论你的电脑是否开机，团队成员都可以稳定访问该接口。

我可以直接在浏览器中访问云端 mock URL 吗？

对于 GET 请求，可以。只要把带有 apifoxToken query 参数的完整 URL 粘贴到浏览器地址栏中，就可以直接看到 JSON 响应。对于其他 HTTP 方法，或者为了避免 Token 留存在浏览器历史记录中，更推荐使用 curl、接口调试工具或前端代码，并通过 header 传递 Token。

如果请求里不带 Token，会发生什么？

如果你的访问控制已设置为 Token 鉴权，那么所有未携带有效 apifoxToken 的请求都会被拒绝。你可以通过 query 参数、请求 header，或表单请求中的 body 参数来传递它。如果你是在已经分享普通 URL 之后才启用 Token 鉴权，记得提前通知所有调用方，以免他们在接口报错后才发现需要补充 Token。

如何生成符合指定国家或地区格式的 mock 数据？

你可以在“基本设置”中设置项目语言，也可以在“功能设置 > Mock 设置”里为整个项目覆盖 locale，或者在 mock 表达式中通过 locale 参数覆盖单个字段，例如 {{$person.fullName(locale='ja')}}。优先级规则是字段级高于项目级，项目级高于“基本设置”中的默认值。结合智能 mock 功能后，这种基于数据模型的真实数据生成能力会更完整。

我应该选择云端 mock（Cloud Mock）还是无头 mock 工具？

如果你的团队希望 API mock 能直接围绕接口设计展开，并且更倾向于使用托管式、低维护成本的方案，那么云端 mock 通常更合适。若你的核心需求是把 mock 深度集成进完全无 GUI 的自动化构建流程，那么无头 mock 工具可能会更匹配。关于两类方案的差异与适用场景，可以进一步查看无头 mock 工具的调研内容。归根结底，OpenAPI Initiative 规范是很多此类工具共同依赖的基础，因此无论最终选择哪种路线，先写好一份清晰规范的 API 描述，后续都会轻松很多。

总结

只存在于本地电脑上的 mock，通常只能解决单个人的开发阻塞；而云端 mock 则能把它升级为一个公开可访问的 mock.apifox.com URL，供整个团队协作开发和联调使用。它支持 Token auth 来限制访问，也支持 locale 本地化控制，让特定地区的 mock 数据看起来更真实。只需要设计好接口、开启云端开关并分享链接，前端开发就不必再被后端进度牵制。下载 Apifox，创建你的第一个可共享云端 mock 服务端，免费即可开始使用，无需信用卡。