📚 课程目录第4章技术选型与工具对比

技术选型与工具对比：找到最适合你的 Mock 方案

说实话，技术选型这件事，我见过太多团队一上来就拍脑袋决定了。结果呢？开发到一半发现工具不支持某个协议，或者性能扛不住压力，最后只能回炉重造。在我参与过的十几个 Mock 项目中，光是因为选型失误导致返工的，至少就有 3 个。所以这一章咱们就把市面上主流的方案掰开揉碎，看看它们到底适合什么场景。

这里我把几个核心工具和自研方案放在一张图里，你先有个整体印象，后面我们再逐个细聊。

1. WireMock：轻量级 HTTP Mock 首选

WireMock 是我个人用得最多的工具，没有之一。它最大的特点就是「轻」。一个 jar 包就能跑起来，Java 项目集成极其方便。它的核心能力是 HTTP/HTTPS 协议的 stub 配置和请求验证。

咱们看一个最简单的例子：

// WireMock stub 配置示例
stubFor(get(urlEqualTo("/api/user/1"))
    .willReturn(aResponse()
        .withStatus(200)
        .withHeader("Content-Type", "application/json")
        .withBody("{\"id\":1,\"name\":\"测试用户\"}")));

你看，三行代码就搞定一个接口模拟。不过我要提醒你，WireMock 对非 HTTP 协议的支持比较弱，如果你需要模拟 TCP、gRPC 这类协议，它就不太行了。

我的经验： 有一个支付网关项目，我们用 WireMock 模拟了支付宝和微信的回调接口，开发阶段跑得飞快。但后来需要模拟 WebSocket 推送时，发现 WireMock 原生不支持，只能临时换方案。所以前期一定要摸清你的协议需求。

2. MockServer：协议全面，录制回放是亮点

MockServer 比 WireMock 重一些，但它支持更多协议：HTTP、HTTPS、WebSocket、TCP、SOAP 等。我最喜欢它的「录制回放」功能——你可以把真实服务的请求响应录下来，然后直接当 Mock 用。这在新老系统迁移时特别有用。

// MockServer 预期配置示例
when(
    request()
        .withMethod("GET")
        .withPath("/api/order/1001")
).respond(
    response()
        .withStatusCode(200)
        .withBody("{\"orderId\":1001,\"status\":\"paid\"}")
);

它还有一个管理界面，可以动态查看和修改 Mock 数据。不过我遇到过一个问题：在并发量较高的场景下，MockServer 的资源占用会比 WireMock 高出不少。这个你要心里有数。

避坑指南： 我曾经在生产环境的预发布阶段使用 MockServer 做压力测试，结果它自己先扛不住了——内存飙到 2GB 以上。它更适合功能测试和集成测试，纯压力测试场景建议用轻量方案。

3. Mountebank：多协议与动态注入的瑞士军刀

Mountebank 是一个很有意思的工具。它支持 HTTP、HTTPS、TCP、SMTP 等多种协议，而且你可以在不重启服务的情况下动态注入新的 Mock 规则。它的配置方式是通过 REST API 动态管理的，非常灵活。

// Mountebank impostor 配置（JavaScript）
const impostor = {
  protocol: 'http',
  port: 8080,
  stubs: [{
    predicates: [{
      equals: { method: "GET", path: "/api/product/42" }
    }],
    responses: [{
      is: {
        statusCode: 200,
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ id: 42, name: "测试商品" })
      }
    }]
  }]
};
// 通过 POST /impostors 动态注册

Mountebank 的跨平台特性很好，Node.js 写的，任何环境都能跑。但它的社区相对小一些，遇到复杂问题查资料比较费劲。我的建议是：如果你的团队技术栈比较杂（Java、Go、Python 都有），Mountebank 的统一方案能省不少事。

4. 自研方案：什么时候该自己造轮子？

说到自研，很多人第一反应是「不要重复造轮子」。这话对，但不全对。我参与过两个自研 Mock 平台的项目，都是在以下场景下被迫选择的：

协议高度定制： 内部私有协议，开源工具无法直接支持
需要深度集成 CI/CD 链路： 要和内部监控、告警、流量平台打通
安全与合规要求： 某些金融、政务项目不允许引入未经安全审计的开源组件

自研的好处是「想要什么就有什么」，但代价也很现实：开发成本 2-4 周，长期维护至少需要 1-2 人持续投入。如果你只是想快速验证一个想法，别自研；如果是团队长期的基础设施，可以认真考虑。

  我的判断标准： 如果开源工具能覆盖 80% 以上的需求，优先用开源。只有当你的场景属于那剩下的 20%，且短期内没有更好的替代方案时，才启动自研。

5. 选型考量因素：一张表说清楚

讲完了四个方案，咱们用一个表格把它们放在一起对比。我团队在实际选型时，通常会评估以下六个维度：

对比维度	WireMock	MockServer	Mountebank	自研方案
协议支持	HTTP/HTTPS	HTTP+WebSocket+TCP+SOAP	HTTP+TCP+SMTP 等	完全可控
易用性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐（需开发）
性能	高	中	中	按需优化
社区活跃度	高（Star 6k+）	中（Star 4k+）	低（Star 1.5k+）	无社区
维护成本	低	中	中	高
最适合场景	Java 微服务 · HTTP接口	多协议集成 · 录制回放	跨语言团队 · 动态Mock	私有协议 · 深度定制

看完这张表，你大概能感受到：没有哪个方案是「银弹」。WireMock 胜在轻量和 Java 生态；MockServer 赢在协议全面；Mountebank 强在灵活和跨平台；自研方案则是一把双刃剑。

我的建议： 如果你还在犹豫，不妨从 WireMock 开始。它上手成本最低，覆盖了绝大多数前台服务的 Mock 场景。等到哪天它真的满足不了你了，再迁移到 MockServer 或自研也不迟。我在好几个项目里都是这么干的——先用 WireMock 快速跑通，后面再按需升级。

6. 聊聊选型之外的事

工具选好了，只是第一步。真正让 Mock 体系发挥作用的是：团队约定 + 持续维护。我见过一个团队选了 WireMock，但每个人各写各的 stub，接口路径、返回格式完全不统一，最后 Mock 数据比真实服务还难维护。所以不管你选哪个工具，一定要在团队内形成规范和共享机制。

说白了，工具是骨架，规范才是血肉。没有规范，再好的工具也白搭。