WireMock、MockServer、Mountebank三剑客对比：模拟服务选型与实战指南

最近接手了一个对接第三方支付回调的活儿，上游只提供了一套预发环境，一到晚上就关闭，前端和联调进度全被卡住。我的第一反应不是去催运维，而是在本地把支付回调接口“冒充”了出来——用一个进程监听 8080 端口，把成功、失败、超时、乱序几种响应按需返回。这就是常说的模拟服务（Mock Service），行业里更正式一点的叫法是服务虚拟化（Service Virtualization）。

有人可能会嘀咕：Mock 工具不是到处都是吗？Postman、ApiPost 不也能 Mock？但那些只是接口调试层面的临时替身，而真正要在开发联调、自动化测试、故障演练、契约测试里充当“虚拟上游”的开源工具，最常被翻牌的就是 WireMock、MockServer 和 Mountebank 这三样。这几个名字经常出现在同一个技术话题里，但它们的定位、擅长场景和配置思路差异很大。这篇文章我打算把三个工具放到同一张工作台上，从原理、配置、选型到踩坑做一次全景式拆解，方便后端开发、测试开发和负责环境治理的同事直接拿来参考。

1. 模拟服务为什么成了联调时代的“刚需”

1.1 开发链路变长后，接口依赖成了最大阻塞

以前单体应用时代，大多数接口都在同一个进程里，前后端联调最多等一等页面渲染。现在不一样了，微服务拆分、前后端分离、第三方开放平台接入，一条业务链路动辄跨五六个系统：前端要调后端、后端要调订单中心、订单中心要回调支付网关、支付网关还要推消息给对账系统。

只要这条链路上任何一个服务没就绪，下游所有开发都会被卡住。尤其是支付回调、短信发送、消息推送这类依赖外部平台的场景，环境不稳定不在你手里，想复现一个异常响应更是难上加难。这其实是模拟服务最朴素的诞生理由：把不可控的依赖变得可控，把还没上线的服务变成“假的可运行版本”。

1.2 “接口替身”到底要替什么

很多第一次接触模拟服务的人，以为 Mock 就是“固定返回一段 JSON”。如果只是这么想，后面一定会踩坑。

一段真实的联调里，Mock 服务至少要替掉上游的这几类行为：

• 正常响应：返回约定好的成功结构，值和字段不能变。
• 异常响应：比如 4xx、5xx、业务码非 0，用来检查下游容错。
• 延迟响应：模拟超时、慢接口，验证调用方的超时重试逻辑。
• 动态响应：同一个接口，根据请求体里的金额、订单状态、门店编号返回不同结果。
• 状态流转：比如“已支付→已退款→已关闭”，每次调用返回不同状态，像真实系统一样有状态记忆。
• 请求校验：能把“请求到底有没有来、参数对不对、头信息是否完整”记录下来。

所以，“可编程的假上游”才是正解。所谓模拟服务，本质上就是一台轻量级的、可配置的、能模拟状态和故障的HTTP服务，只不过它不接入真实业务逻辑。

1.3 为什么三剑客会出现在同一话题里

WireMock、MockServer、Mountebank 经常被放在一起比较，但它们并不是互相替代的关系。我自己的理解是，三者代表了完全不同的设计取向：

• WireMock 像一个“替身演员”：它专注于把 HTTP 接口演得足够像，能录能放，能动态返回，适合把真实依赖“搬运”到本地。
• MockServer 像一个“黑盒记录仪”：它不仅能扮演服务，还把“验证某个请求是否发生过”做成了核心能力，适合集成测试里做行为断言。
• Mountebank 像一个“协议翻译器”：它能模拟的协议范围更宽，TCP、SMTP、HTTPS 都能上，几乎可以作为更多底层服务虚拟化场景的最后兜底。

这样一来，三者其实是可以协同的。接下来逐个拆开看。

2. WireMock：最像“真实服务”的HTTP替身

2.1 快速把一个接口“假装”上线

WireMock 是我日常用得最多的工具，没有之一。它能以 Standalone 进程运行，也支持 Docker、JUnit Rule、Spring Boot 集成，最让我喜欢的是“mappings 目录热加载”的方式——放一个 JSON 文件进去，服务立即生效，不需要重启。

docker run -it --rm -p 8080:8080 \ -v $PWD/mappings:/home/wiremock/mappings \ wiremock/wiremock:latest

然后在./mappings目录下新建一个payment-callback.json：

{ "request": { "method": "POST", "urlPath": "/api/payment/callback", "bodyPatterns": [ { "contains": "\"orderId\": \"A1001\"" } ] }, "response": { "status": 200, "jsonBody": { "code": 0, "message": "notify success" }, "fixedDelayMilliseconds": 100 } }

这样客户端往POST http://localhost:8080/api/payment/callback发请求，只要 body 里包含orderId=A1001的片段，就会收到一个延迟 100ms 的成功响应。

注意我特意用了urlPath而不是url。很多人在 WireMock 里分不清这两个字段：url是“完整匹配”，包含查询参数；urlPath只匹配路径部分，查询参数单独用queryParameters配置。如果你在url里写死了一个带?orderId=xxx的完整地址，后续查询参数顺序一变，匹配直接失败，排查起来非常隐蔽。

2.2 动态响应：从死数据到会算结果

固定返回 JSON 只是入门。WireMock 真正强大的是动态响应能力，它内置了 Handlebars 模板引擎，可以在 response 中读取请求体的字段。

比如支付回调的应答里，要求回显这次回调的流水号：

{ "request": { "method": "POST", "urlPath": "/api/payment/callback" }, "response": { "status": 200, "body": "{\"code\": 0, \"message\": \"success\", \"echoNo\": \"{{jsonPath request.body '$.bizNo'}}\"}" }, "metadata": { "responseTemplate": true } }

注意必须配置"responseTemplate": true或者启动时加上--global-response-templating，模板才会生效。我第一次在 Docker 里启用模板时就没开这个开关，结果返回的是一段“{{jsonPath…}}”原始文本，前端直接炸了。

WireMock 还支持延迟分布、故障注入、HTTPS、Basic Auth 校验。我在本地模拟超时场景时，一般用这样的响应配置：

{ "response": { "status": 200, "fixedDelayMilliseconds": 3000 } }

如果要模拟更真实的抖动场景，可以用delayDistribution配置均匀分布或指数分布，比如每次延迟在 800ms 到 1200ms 之间波动。这样调用方测试超时重试时，不会被一个固定延迟“骗过去”。

2.3 录制回放：把真实依赖“搬到本地”

WireMock 最实用的能力之一是录制回放（Record & Playback）。当上游真实环境能访问、但网络或环境不稳定时，你可以先让 WireMock 代理真实接口，把所有请求响应录制成本地 stub。

启动方式也很简单：

docker run -it --rm -p 8080:8080 \ -v $PWD/mappings:/home/wiremock/mappings \ wiremock/wiremock:latest \ --proxy-all https://real-api.example.com \ --record-mappings

此时访问本地的任意/api/xxx，WireMock 会转发到真实地址，并把交互记录到mappings目录里。这种方式特别适合把某个预发环境的一整套接口“复刻”到本地测试环境。

但录制回放有几个非常需要警惕的地方：

• 录制结果里通常包含真实环境的时间戳、token、订单号，回放时这些值已经过期，需要做脱敏和替换。
• 如果接口有状态流转（比如先创建、后查询、再关闭），录制的多个 stub 之间可能会互相干扰。
• 真实接口返回的错误响应也会被录进去，回放时你很难区分哪个是“正常错误”、哪个是“环境故障”。

所以我的习惯是：录制只作为初始数据，生产环境跑一次回放后，还要手动审一遍 mappings 文件，把动态字段替换成 Handlebars 模板，把不需要的 stub 删掉。

2.4 WireMock 的坑

我踩过的 WireMock 坑主要集中在四个方面：

第一个是匹配优先级。如果同时配置了/api/user和/api/user/{id}这种路径，WireMock 会默认把“相似度高”的匹配项优先，但这不是绝对的。最好在 JSON 里显式配置"priority"字段，数字越小优先级越高，避免命中不符合预期的 stub。

第二个是中文乱码。WireMock 的jsonBody字段如果待返回内容含中文，有时会因为编码不一致导致乱码。建议统一在 response 里显式加"headers": { "Content-Type": "application/json; charset=utf-8" }，不要依赖默认编码。

第三个是场景状态没重置。WireMock 的 Scenarios 功能支持模拟状态机，但你跑完自动化测试后如果没清场景状态，下一个用例会从上一个用例的结束状态继续跑，导致断言总是失败。最好在测试的 teardown 里调用 admin API 重置 scenarios。

第四个是 HTTPS 证书。WireMock 自带了一个自签名证书，本地测试调用方如果开启证书强校验，会报 SSL 错误。简单的做法是在测试环境关掉校验，最稳妥的做法是把 WireMock 的证书导入信任库。

3. MockServer：把“请求验证”变成一等公民

3.1 和 WireMock 的本质区别

WireMock 的核心视角是“返回一个像样的响应”，它对“请求到底有没有来、来了几次、参数对不对”并不那么关心。但集成测试里，我们经常需要回答这类问题：订单服务在超时后应该重试三次，重试的请求体是不是带了上一次的任务 ID？退款状态下，支付回调接口不应该再被调起……

MockServer 就是为这类“行为验证”而生的。它可以在响应请求的同时记录所有交互，并提供一个verify能力来判断请求是否匹配、匹配次数是否正确。

3.2 expectation 与 verify：一边模拟一边检查

用 Java 客户端看是最直观的：

MockServerClient client = new MockServerClient("127.0.0.1", 1080); client.when( request().withMethod("POST").withPath("/api/order") .withBody("{\"sku\":\"A1001\"}") ).respond( response().withStatusCode(201) .withHeader("Content-Type", "application/json") .withBody("{\"orderId\":\"1001\"}") );

当被测服务发起请求后，再执行验证：

client.verify( request().withMethod("POST").withPath("/api/order") .withBody("{\"sku\":\"A1001\"}"), VerificationTimes.exactly(1) );

如果POST /api/order没有收到请求，或者收到的次数和期望不一致，verify会直接抛异常，测试自然失败。这种“模拟 + 断言 + 验证”的一体化流程，比我们自己统计请求日志再断言要舒服得多。

还有更精细的验证方式。比如验证请求头里包含认证信息：

client.verify( request().withMethod("GET").withPath("/api/user") .withHeader("Authorization", "Bearer test-token"), VerificationTimes.atLeast(1) );

它本质上维护一个请求日志库，任何经过 MockServer 的请求都会落库，验证时基于日志做匹配。

3.3 代理与请求转发：真实服务的“旁路摄像头”

MockServer 不只是一个模拟器，它还能配置forward行为，把匹配到的请求转发到真实服务。例如：

client.when( request().withMethod("GET").withPath("/api/real") ).forward( forward().withHost("real-api.internal").withPort(8080) );

这个能力在实际联调里很有用：你可以让 MockServer 监听一个统一入口，某一些路径走 mock 数据，另一些路径走真实上游，从而实现服务没有完全迁移完成时的灰度联调。它像在真实服务前面加了一个“旁路摄像头”，你能看到全部流量，又能对所有请求做动态干预。

3.4 管理界面与日志复盘

MockServer 的请求日志默认是通过 HTTP API 查询的。访问管理端口，可以直接从日志接口看到最近哪些请求被匹配到了哪个 expectation，哪些请求没匹配上：

curl http://localhost:1080/mockserver/retrieve?type=REQUEST

如果发现调用方一直拿不到预期响应，第一件事就是查这个日志列表，而不是去猜配置。这一点在调试复杂报文时非常省力。旧版本里还带一个 Dashboard 页面，新版本逐渐改成了统一的管理 API，具体以你手里的版本为准。

3.5 MockServer 的坑

MockServer 的坑和 WireMock 有一些相似，但它的坑更集中在测试生命周期上：

第一个是 expectation 污染。MockServer 启动后，expectation 是全局的，如果测试用例 A 创建了一个 expectation，用例 B 没清理，B 里同名接口就会收到 A 的预设响应。建议每个测试类的@BeforeEach清理 expectation，@AfterEach再清理一次，保证互不干扰。

第二个是 verify 的异步性。MockServer 记录请求日志不是立刻落库的，断言前如果没有等待，verify 可能查不到刚发生的请求。尤其在被测服务用异步线程发起调用时，需要在 verify 前加一个轮询等待，或者使用 MockServer 自带的 Netty 启动器配合 Awaitility 等待。

第三个是代理模式下的路径重写。使用 forward 时，如果目标服务的 context path 和后端真实服务不一致，需要手动设置 header 或 path 重写。否则就会出现“本地能收到，转发到真实环境后 404”的诡异问题。

第四个是 Docker 容器内存占用。MockServer 基于 Netty，功能丰富的同时内存占用也比 WireMock 高不少。如果只是简单 mock，没必要为一个接口起一个 MockServer 容器，不然 CI 内存压力会明显增加。

4. Mountebank：多协议与故障注入的“瑞士军刀”

4.1 为什么要引入第三种工具

很多企业系统里，除了 HTTP，还有数不清的非 HTTP 依赖：老物流系统走 TCP 长连接、邮件服务走 SMTP、短信平台走 SMPP、物联网设备走 MQTT 或自定义端口协议。WireMock 和 MockServer 基本固定在 HTTP/HTTPS 生态内，遇到这些非 HTTP 协议，它们就鞭长莫及了。

Mountebank 的名字你可能会觉得陌生，但它出生的原因很直接：提供一个免费的、开源的、不依赖特定语言的“服务虚拟化”工具，支持 HTTP、HTTPS、TCP、SMTP、SMS 等协议。它有一个抽象概念叫 imposter（桩），一个 imposter 就是“监听某个端口的虚拟服务”，协议不同，端口不同，行为不同。

4.2 imposters 的概念与配置

Mountebank 的原生语言是 JavaScript，安装非常简单：

npm install -g mountebank mb start --port 2525

默认2525是管理端口，接收 REST API 操作。创建数据的 POST 请求大概是这样的：

{ "port": 4545, "protocol": "http", "name": "order-callback-mock", "stubs": [ { "predicates": [ { "equals": { "method": "POST", "path": "/callback" } } ], "responses": [ { "is": { "statusCode": 200, "headers": { "Content-Type": "application/json" }, "body": "{\"ok\": true}" } } ] } ] }

向管理接口提交：

curl -X POST http://localhost:2525/imposters \ -H 'Content-Type: application/json' \ -d @imposter.json

然后访问http://localhost:4545/callback，使用的是 POST 方法，就会命中预设响应。这里要注意predicates和responses都是数组，一个 imposter 可以包含多个 stub，每个 stub 支持多个 predicate 条件，命中后按顺序进入多个 response，这种结构非常灵活。

4.3 动态响应与故障注入

Mountebank 的差异化能力，体现在behavior字段上。它可以在不改动 stub 本身的前提下，给响应附加“延迟”“重复”等行为。

比如模拟一个 3 秒后才响应的 TCP 服务：

{ "responses": [ { "is": { "data": "SERVICE OK" }, "behavior": { "wait": 3000 } } ] }

注意这里的data字段是针对 TCP 协议的，HTTP 协议用body字段。很多从 HTTP 工具转过来的同学，第一次用 Mountebank 模拟 TCP 时会把body拿来给 TCP 响应用，结果服务端收到的根本不对。TCP 层是个字节流，它没有 HTTP 的“请求体”“响应体”概念，所以 Mountebank 用data来表示原始字节。

Mountebank 还支持repeat字段，让同一个响应连续出现 N 次后再切到下一个响应。这在模拟“前三次重试失败、第四次成功”的场景时非常有用，配置上比 WireMock 的状态机更直观。

更强大的还有inject，它允许你通过 JavaScript 函数动态生成响应。比如根据请求 source 的 IP 地址返回不同内容，或者把请求体里的字段处理后放到响应里。功能上限很高，但也要小心：JavaScript 函数如果抛异常，Mountebank 会返回 500，排查时看不清是业务问题还是注入脚本问题。我的经验是，inject里的逻辑越简单越好，复杂逻辑不要放在 mock 工具里，否则就是把测试代码埋在了一个不透明的黑盒里。

4.4 多协议的一个实际场景：TCP 模拟

举一个我实际遇到过的场景。某个老物流系统基于 TCP 长连接，报文前 4 字节是长度字段，后面跟着 JSON 字符串。为了在测试环境模拟物流状态推送，我用 Mountebank 起了这样一个 imposter：

{ "port": 9999, "protocol": "tcp", "mode": "text", "stubs": [ { "predicates": [ { "contains": { "data": "queryStatus" } } ], "responses": [ { "is": { "data": "{\"status\":\"DELIVERED\",\"(orderNo\":\"A1001\"}" } } ] } ] }

客户端照常向9999端口发请求，测试环境就能收到一个固定的物流状态。等真实物流环境可用后，再调整配置文件把服务切到真实依赖。整个过程不需要改一行应用代码，这是 Mountebank 在多协议场景里不可替代的价值。

SMTP 模拟也是同样的思路。你可以让被测系统把邮件发送到 Mountebank 开出的 SMTP imposter 端口，然后通过管理接口拉取收到的邮件内容，校验收件人、主题、正文是否正确。

4.5 Mountebank 的坑

Mountebank 的坑比较有“个性”。

第一个坑是协议匹配的粒度问题。Mountebank 对 HTTP 请求的匹配能力不如 WireMock 精细，像 JSONPath、XPath 这类高级匹配，它默认是不支持的。如果你需要针对某个嵌套 JSON 字段做精确匹配，可能只能写 JavaScript 谓词，配置成本一下子高很多。

第二个坑是管理端口和业务端口混淆。mb start --port 2525是管理端口，imposter 的业务流量走各自配置的端口。如果你把业务调用指向管理端口，会发现服务一直能通但什么都没发生，因为它把请求发给了管理 API。

第三个坑是 inject 的异步问题。Mountebank 的 inject 需要返回一个 Promise 或者同步返回值。如果你在里面用了一个异步函数但没有正确处理 Promise，响应可能永远不会返回。我建议先在 Node REPL 里把函数单独跑通，再贴到配置里。

第四个坑是性能。Mountebank 在大量并发和复杂 predicate 场景下，处理能力明显不如 Java 社区的两大工具。它更适合联调、测试和小规模故障演练，不适合压测阶段的流量模拟。压测还是建议直接用服务端的 mock 接口或 Locust 这类工具。

5. 三种工具同台对比：如何快速选型

5.1 一张表看清边界

很多文章喜欢把这三者列成“哪个更好”的竞技场，我反而觉得，选型的关键是看清“边界”。我把它们在日常项目里的关键差异整理成了表格：

需要注意，这个表描述的是“默认形态下的差异”。实际上三种工具都在持续迭代，某些能力边界会随着版本变化而模糊，但大方向是稳定的。

5.2 我的选型经验

落到具体项目里，我的选型经验可以浓缩成三句话：

第一，纯 HTTP、目标是快速把上游服务“变出来”，闭眼选 WireMock。它启动快、配置简单、社区资料多，前端和后端都能快速上手。哪怕团队里没人用过 mock 工具，WireMock 的文档也足够友好。

第二，测试代码里需要断言“某个请求是否发生、参数是否正确”，用 MockServer。它把验证行为内置到 SDK 里，能让断言直接写在测试用例中。WireMock 虽然也有verify相关功能，但整体设计不像 MockServer 这样围绕行为验证展开。

第三，遇到 TCP、SMTP、二进制协议，或者要模拟非常复杂的故障链，上 Mountebank。它的抽象能力足够通用，多协议支持是另外两个工具的盲区。如果团队没有 Node.js 基础，也不用担心，Mountebank 是通过 REST API 管理的，写配置不要求懂 JavaScript，只有inject才需要。

5.3 混合使用的可能性

这里想说一个很多人忽略的点——这三个工具不是互斥的，完全可以共存于同一个联调环境。

我之前在一个电商中台项目里，就是同时跑着这三个服务：订单中心前后端联调用 WireMock，支付回调的行为断言放在 MockServer 里，老的 TCP 物流推送接口则挂 Mountebank。通过 Docker Compose 统一编排，把三套服务分别映射到不同端口，用 nginx 或者 hosts 配置做入口分流，团队每个人本地都能拉起一套完整的“虚拟上游环境”。

这样做的代价是需要维护三套配置，但收益也非常明显：每一层依赖都是可控的，联调速度大幅提升，测试环境也不再因为上游抖动而集体返工。

6. 我的落地经历：一次支付回调联调踩坑全记录

6.1 项目背景

去年我负责一个电商平台的支付回调模块。支付网关在上游，出了一个测试环境，但每天只在工作时间开放，而且接口经常超时。业务要求联调时，前端必须把“提交订单—跳转支付—模拟回调—更新订单”整条链路走通，测试团队还要求能验证订单服务的重试逻辑。

我当时定了这样一个组合方案：

• 用 WireMock 模拟支付网关的回调接口，前端和各联调方都连它。
• 用 MockServer 做订单服务集成测试的行为断言，重点验证“回调失败后有没有重试、重试次数对不对”。
• 后续另一个老系统需要对接 TCP 物流状态，才引入 Mountebank。

6.2 第一次踩坑：Docker 挂载路径导致配置丢失

最开始的坑非常低级。我在 Docker Compose 里写了这样一段：

services: wiremock: image: wiremock/wiremock:latest ports: - "8080:8080" volumes: - ./mocks:/home/wiremock/mocks

但 WireMock 官方镜像的默认映射目录是/home/wiremock/mappings，而不是/home/wiremock/mocks。结果服务启动后，我放进./mocks的 stub 文件根本没被加载，接口全部 404。当时我还以为是 JSON 语法写错了，排了半天才发现是路径的问题。

正确写法是：

volumes: - ./mocks:/home/wiremock/mappings

这个坑看起来很小，但很容易浪费大量时间。我的建议是：无论用哪种工具，第一件事就是看好官方镜像的 VOLUME 路径，不要想当然。

6.3 第二次踩坑：录制回放的数据污染

后来为了快速给前端提供回调数据，我对支付网关真实环境做了一轮录制回放。录制很顺利，mappings 目录下生成了几十个 stub 文件。但前端在本地联调时发现，回调返回的订单号和浏览器里的订单号对不上，总是差几位数。

排查后才发现，录制回来的 stub 里写死了支付网关当时返回的订单号，而前端的订单号是当前环境新生成的。两个数字对不上，前端就认为回调失败。

解决办法是把 stub 里的固定订单号改成了 Handlebars 模板：

"body": "{\"orderId\": \"{{request.query.orderId}}\", \"status\": \"SUCCESS\"}"

这样前端每次请求带什么订单号，回调就返回什么订单号。录制回放很好用，但录完必须做“数据脱敏和动态化”，否则录下来的只是一堆会过期的死数据。

6.4 第三次踩坑：mock 延迟设置不当反而引发雪崩

当时为了模拟正常回调速度，我给 WireMock 配置了 200ms 固定延迟。但联调时发现，前端网关的超时阈值是 500ms，加上网络波动，偶尔会触发重试。重试又叠加延迟，导致回调接口在同一时间收到多笔重复请求，订单服务瞬间被打到高负载。

这件事让我意识到，mock 服务的参数不能拍脑袋。延迟、重试次数、超时阈值必须和真实的 SLO 对齐，比如真实支付网关的 P99 延迟是多少，mock 就应该设置成多少。如果只是为了“模拟快一点”，那 mock 环境测试出来的超时和重试结论，放到生产环境完全没有参考意义。

6.5 沉淀下来的配置目录与团队协作方式

经历了这次联调后，我把一套 mock 配置管理方法沉淀进了团队规范：

mocks/ wiremock/ mappings/ __files/ mockserver/ expectations.json mountebank/ imposters/

所有配置文件都进 Git，和代码版本一起管理。接口变更时，先更新 mock 配置，再跑一遍关联测试，相当于把 mock 配置当成接口契约来维护。

Docker Compose 则是这样组织：

services: wiremock: image: wiremock/wiremock:latest ports: - "8080:8080" volumes: - ./wiremock/mappings:/home/wiremock/mappings mockserver: image: mockserver/mockserver:latest ports: - "1080:1080" environment: MOCKSERVER_PROPERTY_FILE: /config/mockserver.properties volumes: - ./mockserver:/config mountebank: image: ... # 或直接用 node 运行 ports: - "2525:2525" - "9999:9999" volumes: - ./mountebank:/imposters

这样任何人拉下代码，执行一条docker compose up -d，就能在本地起一套完全一致的 mock 环境。

6.6 如果让我重做一次，我会怎么搭

如果再给我一次机会，我会在项目刚开始时先把接口清单理出来，而不是等上游环境出问题后才临时补 mock。具体来说：

• 把所有依赖接口整理成一张表，标注正常响应、异常响应、超时场景分别是什么。
• 为每个关键接口至少准备两种状态的 stub：成功和失败。
• mock 环境统一分配端口范围，建立环境说明文档，避免几个人抢同一个端口。
• 在 CI 流水线里加上一个 smoke test，每次 mock 配置变更后自动跑一遍关键链路，防止协议字段漂移。

这些工作看起来繁琐，但很大程度上能避免联调阶段的手忙脚乱。

最后分享一个小习惯：我从来不把 mock 配置当作“临时用来应付联调的东西”用完就删，而是把它当作接口契约文档来维护。每次上游接口变化，我先更新 mock，再跑一遍关联测试，让 mock 环境成为接口变更的第一道防线。这个习惯帮我在几次大版本升级里提前拦住了不少“上游改了参数，下游还在用老字段”的问题。如果你现在还没有一套团队共用的 mock 环境，我建议从 WireMock 先跑起来，成本低、见效快，等你遇到 HTTP 之外的需求时，再一步一步把 MockServer 和 Mountebank 引进来也完全不迟。