API Mock 实战：前后端并行开发与契约测试指南

API Mock 是解决”后端接口没好、前端只能干等”的核心手段：在契约确定后，用模拟服务返回假数据，让前后端并行开发真正跑起来。本文对比 Mockoon、Prism、WireMock 三款工具，并演示如何用 Pact 把接口约定变成可执行的契约测试，把联调成本从”等后端”降到”跑测试”。它和 API 文档工具、API 调试工具 是前后端协作的三件套。

没有 Mock 的团队，前端往往要等后端把接口、字段、错误码都敲定才能开工，一条关键链路卡住就全员阻塞。而”先定契约、再各自实现”的模式，让双方只依赖一份 OpenAPI 描述并行推进——这正是 API Mock 与契约测试要解决的问题。下面从为什么需要，到三款工具怎么选，再到把契约写进测试流水线，一步步落地。

一、为什么需要 API Mock

前后端协作的瓶颈通常不是”写代码慢”，而是”互相等”。后端字段设计时频繁改动，前端写死的假数据一上线就崩；等到联调才发现响应结构对不上，返工成本极高。API Mock 把”接口长什么样”提前固化成契约，三方各取所需：

• 前端：接口未实现即可联调页面、写请求层、跑 前端自动化测试。
• 后端：契约即文档，实现时有明确字段与状态码约束。
• 测试：用契约测试在 CI 里阻断”破坏接口”的提交。

关键点：Mock 不是”随便返回点数据”，而是以契约（OpenAPI / Pact 文件）为准。否则前端联调用假结构，后端上线用真结构，等于白 Mock。

二、三款工具横评：Mockoon / Prism / WireMock

选工具先看场景：要”可视化零代码”选 Mockoon；要”契约即 Mock、改 OpenAPI 自动生效”选 Prism；要”可编程、顺便做契约测试”选 WireMock。

三、Mockoon：GUI 零代码模拟接口

Mockoon 是桌面 GUI，拖拽即可建环境、路由、响应体，适合前端同学不写代码就能跑起一个本地 Mock 服务。建好后在 Environment 里设端口（如 3001），加一条 GET /api/users 返回 JSON 即可。

# 用 CLI 启动已导出的 Mockoon 环境（团队共享同一份 json）
mockoon-cli start --data ./mockoon.json --port 3001

# 前端直接请求，结构完全按契约来
curl http://localhost:3001/api/users
# 返回：{"code":0,"data":[{"id":1,"name":"张三"}],"message":"ok"}

进阶：Mockoon 支持根据请求参数返回不同响应、加随机延迟模拟弱网、用 {{faker 'name.firstName'}} 生成假数据。团队把 mockoon.json 提交到仓库，前端新人 clone 就能一键起服务，比口头约定接口稳得多。

四、Prism：OpenAPI 即 Mock 服务

Prism 的思路最优雅：你写一份 OpenAPI（Swagger）描述文件，它自动按 schema 生成”合法”的 Mock 响应，连字段类型、示例值都从契约里取。改了 OpenAPI，Mock 行为同步变，真正做到”契约单一来源”。

# 安装并启动（无需写一行 Mock 代码）
npm i -g @stoplight/prism-cli
prism mock openapi.yaml --port 4010

# 请求契约里存在的路径
curl http://localhost:4010/api/users
# Prism 按 openapi.yaml 的 schema 返回示例数据

# 请求契约里【不存在】的路径，Prism 返回 404 并提示契约未定义
curl http://localhost:4010/api/not-exist

Prism 还会做”契约校验”：你可以用它反向校验后端实现是否违契约（prism proxy 模式把请求转发真实服务并比对响应）。这与 API 文档工具 天然互补——文档（openapi.yaml）既是门面，又是 Mock 与校验的单一真相源。

五、WireMock：可编程 Mock + 契约测试

当场景变复杂（按 Header 路由、按状态机返回、录制真实流量回放），WireMock 用”规则”描述行为，可用 JSON 或 Java DSL。它常被放进后端集成测试，作为”可控的下游依赖”。

// 一个 WireMock 规则（standalone 用 JSON 等价表达）
{
  "request": { "method": "GET", "urlPath": "/api/orders/1" },
  "response": {
    "status": 200,
    "headers": { "Content-Type": "application/json" },
    "jsonBody": { "id": 1, "status": "PAID", "amount": 99.0 }
  }
}

在测试里启动 WireMock，把”支付网关””短信服务”等不稳定外部依赖替换成确定响应，CI 就再也不怕第三方抖动。下面这段 JUnit 5 让订单服务指向本地 WireMock，验证超时兜底逻辑：

@WireMockTest(httpPort = 8089)
class OrderServiceTest {
    @Test
    void should_fallback_when_payment_timeout() {
        stubFor(get("/api/pay/1").willReturn(
            aResponse().withFixedDelay(5000).withStatus(504)));
        // 订单服务配置 payment.baseUrl=http://localhost:8089
        OrderResult r = orderService.pay(1L);
        assertThat(r.getStatus()).isEqualTo("FALLBACK");
    }
}

六、契约测试：把接口约定变成可执行用例

Mock 解决”开发期并行”，契约测试解决”上线期回归”。Pact 是最常用的消费者驱动契约（CDC）框架：前端（消费者）记录”我期望的请求与响应”，生成 Pact 文件；后端（提供者）在 CI 里重放验证”我是否满足所有消费者的预期”。一旦破坏契约，提交直接被拦。

// 消费者端（前端/调用方）用 Pact 记录期望
@Pact(consumer = "web-frontend", provider = "user-api")
public RequestResponsePact getUser(PactDslWithProvider b) {
    return b.given("user 1 exists")
      .uponReceiving("get user")
      .path("/api/users/1").method("GET")
      .willRespondWith().status(200)
      .body(new JsonObject().add("id", 1).add("name", "张三").toString())
      .toPact();
}

// 提供者端 CI：重放所有消费者 Pact，验证自身实现
// ./mvnw pact:verify  （需配置 pact broker 或本地 pact 文件）

契约测试的价值在于”解耦发布节奏”：前端可以独立上线，只要 Pact 仍通过，就说明没破坏后端契约。把它接进 GitHub Actions 流水线，每次 PR 自动跑 provider 验证，比人工联调可靠得多。

七、落地避坑：四张对照表

另外提醒：Mock 服务务必只在本地与 test 环境启用，生产配置里要严格隔离，避免把请求打到假地址。契约文件（openapi.yaml / pact）应纳入版本管理，改动走 PR 评审——它本质上是”接口层的需求文档”，比口头约定靠谱。

八、上线前 Mock 落地清单

把上面串成一份 checklist：① 接口确定即写 OpenAPI，作为 Mock 与文档单一真相源（配合 前端工程化 Monorepo 统一管理）；② 前端用 Mockoon/Prism 本地并行开发；③ 后端用 WireMock 隔离外部依赖做集成测试；④ CI 接入 Pact provider 验证，契约破坏即阻断合并；⑤ Mock 仅限本地/test，生产零依赖；⑥ 契约变更强制 PR 评审。做到这六点，前后端就从”互相等”变成”各自跑、合即对”。

小结

API Mock 与契约测试不是锦上添花，而是中大型团队前后端协作的”交通信号灯”：Mockoon 让前端不等后端，Prism 让契约即服务，WireMock 让测试可控，Pact 让变更可防。它们与 API 调试工具、API 文档工具 共同构成协作闭环。建议从”先写 OpenAPI、本地起 Prism”这件最小动作开始，逐步把契约测试推进 CI。你团队现在是用哪种方式对齐接口的？欢迎评论区聊聊。