企业官网建设流程全解析

说到微信 API 联调，很多人第一反应是“拿真实测试号跑一下就行”。真跑过就会发现，事情远没那么简单：access_token 有每日调用上限，多人开发时你刷一次我刷一次，token 直接被挤下线；微信支付回调需要公网可到达，本地起个服务还得挂内网穿透，微信几秒内重试三次，回调一来测试库就写进一笔脏数据；至于签名验签、nonce、时间戳这套，参数传错微信只回一个冷冰冰的错误码，连日志都没有。更难受的是，微信接口偶尔加字段或改响应结构，不会有人专门通知你，等联调时才发现，通宵排查的又是你。

所以我当时把微信 API 的 Mock Server 和契约测试一起做进了基建。用 WireMock 在本地模拟微信服务端，让开发和测试流程彻底摆脱对真实微信环境的依赖；再用契约测试（Pact）把我们对微信接口的理解固化成契约文件，既用于校验 mock 和真实接口的一致性，也能在接口结构悄悄变化时第一时间报警。这套组合拳跑通之后，团队里再做微信支付、公众号、小程序登录相关需求的同学，基本不再需要碰真实商户号和测试号，新人也敢直接本地起服务动手开发。

这篇文章把我实际搭建、规则编写和集成的完整过程都梳理成可复现的步骤。适合正在做微信生态集成、想给团队搭一套可靠的 mock 基础设施，或者准备引入契约测试又不知道怎么和 mock server 结合的同学参考。

1. 为什么微信 API 对接要同时做 Mock Server 和契约测试

1.1 微信 API 联调的真实痛点

先说清楚我到底被什么逼到要搭这套东西。微信 API 和一般的外部 API 有个显著区别：它不是纯粹的“公网服务”，而是绑定账号体系、频控策略和签名机制的封闭平台。拿最常见的公众号 access_token 来说，官方接口规定获取 token 的调用频率上限是每日 2000 次，而且 token 在有效期内全局唯一。这意味着只要团队里有两个人同时做开发，一个刷新 token，另一个环