你需要一个用于本地开发的伪造 API，并且希望在 30 秒内搞定。不是托管服务，不是 Docker Compose 栈，也不是需要手动点击的 GUI。只需一条命令，读取一个文件，在 localhost 上提供响应即可。

这就是轻量级 mock 服务端的作用。将其指向一个 OpenAPI 规范或一个小数据文件，运行一条命令，你就能获得一个真实的接口——前端或测试可以先用着，等真正的后端慢慢搭建。好用的工具通常以单个二进制文件或可 npx 运行的包形式发布，启动时间不到一秒，几乎不需要配置。当然，也有一些较重的选项运行在 JVM 上，功能更丰富；当你需要高级请求匹配或有状态行为时，它们就派上用场了。

本指南会按“轻量级”的程度，给六款 CLI mock 工具排个序。先从无需安装就能跑的工具讲起，再聊独立的 JVM 服务端，最后介绍通过 Apifox CLI 的集成方案。下文中的每个安装命令和 mock 命令都已根据各工具的官方文档核对过。如果你想了解命令行之外更广阔的领域，最佳 API mock 工具的综述也涵盖了 GUI 和托管选项。

什么是“轻量级”CLI mock 工具

轻量级，指的是占用空间小、摩擦低，而不是功能数量多。在比较这些工具时，可以权衡以下四点：

• 安装体积和运行时。 一个可以通过 npx 运行的纯 Node 包只有几 MB。而一个独立的 JVM 服务端是一个 20 MB+ 的 jar 包，需要 Java 运行时。两者都有效，只是位于这个列表的不同端。
• 启动速度。 一个好的 mock 服务端在你切换回编辑器之前就已经在运行了。基于 Node 的工具冷启动时间远不到一秒。
• 从配置到首次响应。 你能否通过一个文件和一条命令，从零开始获得一个实时接口？最轻量级的工具给出的答案是肯定的。
• 终端优先。 无需账号，无需仪表盘，流程中无需 GUI 步骤。工具读取文件并提供服务，适用于 shell 脚本或 CI 任务。

这些工具按体积从小到大、速度从快到慢排序。Prism、Mockoon CLI 和 json-server 是那些你可以通过 npx 运行而无需全局安装的工具。

Prism (Stoplight)

Prism 只需一条命令就能把 OpenAPI 文件变成实时 mock 服务端。如果你已经有接口定义，这可以说是本列表里成本最低的 mock 方式——它会读取你的 paths、examples 和数据模型，然后提供与之匹配的响应。

npx @stoplight/prism-cli mock ./openapi.yaml

这会在 https://127.0.0.1:4010 上启动一个服务端，连接规范中的每个操作。Prism 会返回你为响应定义的 example，如果没有定义，则会根据数据模型生成一个有效的随机响应。它还会根据规范校验传入的请求，因此格式错误的调用会收到正确的 422 响应，而不是静默通过。如需全局安装，请使用 npm install -g @stoplight/prism-cli 并去掉 npx。

最适合： 遵循接口定义优先原则、希望 mock 严格遵守契约的团队。Prism 采用 Apache-2.0 协议授权，支持 OpenAPI 3.1、3.0、2.0 以及 Postman 集合。

客观局限： Prism 是无状态的。POST 请求不会持久化任何内容，因此它无法模拟“先创建后读取”的流程。它的 mock 质量完全取决于你的接口定义；简略的示例意味着简略的响应。对于追求契约准确性的 mock 来说，这正是其核心所在，它能很好地配合 REST API mock 工具的工作流。

Mockoon CLI

Mockoon CLI 可以根据数据文件运行 mock API，该文件可以是免费的 Mockoon 桌面版导出的文件，也可以是纯粹的 OpenAPI 规范。桌面版允许你可视化地构建路由；CLI 则可以在 CI 或服务端以无头模式运行相同的环境。

npx @mockoon/cli start --data ./mockoon-env.json --port 3000

将 --data 指向 Mockoon 环境文件或 OpenAPI JSON/YAML 文件，它会立即启动服务。如果数据文件来自旧版本的 Mockoon，CLI 会在内存中进行迁移，而不会修改原始文件。如果你希望持久使用 mockoon-cli 命令，可以使用 npm install -g @mockoon/cli 进行全局安装。

最适合： 希望在 GUI 中设计 mock 但在无头模式下运行的团队。它采用 MIT 协议授权，并提供官方 Docker 镜像用于部署。

客观局限： 最复杂的路由是在桌面版中构建的，因此手动编辑 JSON 环境文件会比较繁琐。如果你完全不想使用配套应用，Prism 或 json-server 可以将所有内容保存在一个手动编写的单文件中。

json-server

当你还没有接口定义时，json-server 是伪造 REST API 最快的方法。你只需编写一个描述数据的普通 JSON 文件，它就会围绕该文件生成一个完整的 REST API，包括 GET、POST、PUT、PATCH 和 DELETE。

echo '{ "posts": [{ "id": 1, "title": "hello" }] }' > db.json
npx json-server db.json

这将以真实的 CRUD 方式提供 https://localhost:3000/posts 服务。向 /posts 发送 POST 请求实际上会添加一条记录并写回 db.json，因此你可以免费获得有状态的行为，而 Prism 和 WireMock 开箱即用并不支持这一点。你还可以通过 query 参数进行过滤、排序和分页。目前的 1.x 版本默认会监听文件并在更改时重新加载；如果你希望它始终在 PATH 中，请使用 npm install -g json-server 全局安装。

最适合： 在真实 API 出现之前，需要在一分钟内获得可用 REST 后端的前端开发人员。它采用 MIT 协议授权，是无需接口定义即可实现 RESTful API 的轻量级 mock server 选项之一。

客观局限： 它假设采用资源风格的 REST 架构。深度自定义路由、非 REST 接口或严格的 header 匹配超出了它的处理范围。它是一个原型设计工具，而不是契约验证器。

MockServer

MockServer 是实现精确请求匹配的重量级工具。与上述仅提供规范或数据文件的工具不同，MockServer 允许你定义 mock 期望：通过方法、path 参数、header、query 参数或 body 匹配请求，然后返回你想要的精确响应，包括用于测试超时和错误处理的延迟与故障。

ja va -jar mockserver-netty-5.15.0-no-dependencies.jar -p 1080

这将在端口 1080 上启动 MockServer。然后，你可以向其 REST API 发送 mock 期望来配置行为，或者通过编程方式进行驱动。Node 用户可以跳过原始 jar 包，使用官方封装库：

npm install mockserver-node

const mockserver = require('mockserver-node');
mockserver.start_mockserver({ serverPort: 1080 });

最适合： 需要对请求特征和 mock 响应进行细粒度控制的集成测试。它采用 Apache-2.0 协议授权，支持在单个端口上运行 HTTP、HTTPS 等协议。

局限性： 它是一个 JVM 服务端，因此比 Node 工具更重且启动更慢，而且设置 mock 期望的过程比直接指向一个规范文件要繁琐。如果你只需要提供规范服务，那它就大材小用了；如果你觉得它不再适用，MockServer 替代方案对比中列出了各种权衡。

WireMock (standalone)

WireMock 是另一个成熟的 JVM mock 服务端，在 Java 和 JVM 测试领域非常流行。它的独立运行 jar 包所运行的引擎与你嵌入在 JUnit 测试中的引擎相同，因此你在本地开发中构建的 mock 可以直接带入测试套件中。

ja va -jar wiremock-standalone.jar --port 8080

它在端口 8080 上提供服务。WireMock 从 mappings/ 目录或其 JSON API 读取存根映射（stub mappings），它还可以录制真实流量并将其回放为存根，这在你 mock 无法控制的第三方 API 时非常有用。CI 流程可以使用官方的 wiremock/wiremock Docker 镜像。

最适合： 希望在本地开发和测试套件之间共享同一个 mock 引擎，并需要录制与回放功能的 JVM 团队。它采用 Apache-2.0 协议授权。

局限性： 与 MockServer 一样，它需要 Java 运行时，且启动速度比 Node 选项慢。它的存根映射 JSON 功能强大，但学习成本比单文件数据 mock 更高。如果你来自 JavaScript 阵营，Mock Service Worker (MSW) 替代方案对比介绍了 WireMock 与浏览器优先 mock 工具的差异。

Apifox CLI

上述工具各自解决了 mock 的某一个环节。Apifox 则采用了集成化方案：你的接口定义/规范、mock、测试和文档都集中在一个项目中，而 Apifox CLI 则可以从终端驱动该项目。Apifox 不是开源的；它是一款带有免费版的商业产品。但免费版结合 CLI 为你提供了一个替代方案，让你无需再将独立的 mock 服务端、测试运行器和规范工具拼凑在一起。

Apifox 会根据你定义的每个接口自动生成智能 mock，其响应遵循数据模型的字段类型和命名方式，因此 phone 字段会返回一个合理的电话号码，而不是随机字符串。当你需要针对特定请求返回特定响应时，可以添加 mock 期望。CLI 将这些 mock 资源作为项目的一部分进行管理：

npm install -g apifox-cli
apifox login --with-token 
apifox mock --help

mock 命令组可以配合脚本和 CI 中的项目 mock 期望使用，同时还有针对接口、数据模型、环境和测试运行的命令组。输出是结构化的 JSON，包含 agentHints.nextSteps 字段，这使得 AI 和人类都能使用它。完整的命令范围涵盖在 Apifox CLI 完整指南中。

最适合： 相比于运行三个独立的工具，更倾向于将 mock、规范和测试保持在同一个地方的团队。

坦诚的局限性： 它是一个平台，而不是单一用途的二进制文件，因此它需要项目和登录，而 json-server 则不需要。如果你只需要从一个文件生成一个临时 mock，轻量级工具更胜一筹；如果你已经在 Apifox 中设计 API，那么 mock 已经存在了。

如何选择

根据你现有的资源选择工具。如果你有 OpenAPI 规范，Prism 或 Mockoon CLI 可以直接提供服务。如果你目前一无所有，json-server 可以从 JSON 文件生成 API。如果你需要精确的请求匹配，请选择 MockServer 或 WireMock。如果你希望 mock 与你的设计和测试并存，请使用 Apifox。

粗略规则：追求速度用 npx 工具，追求匹配深度用 JVM 服务端，希望工作流统一而非零散时用 Apifox。

总结

轻量级 mock 的核心在于一个问题：你手头现有的资源能为工具提供什么？接口规范适用于 Prism 或 Mockoon CLI。从零开始则适用于 json-server。需要严格匹配时，请选择 MockServer 或 WireMock。如果你不想运行并配置多个工具，Apifox 可以将 mock 与设计和测试保持同步，并由你编写脚本时常用的同一个 CLI 驱动。

这六款工具均可在终端运行，适配 CI 任务，让你在几秒钟内（而非几小时）即可获得一个伪造的 API。选择能满足你需求的最轻量化工具，仅在确实需要时再增加复杂度。