· 全部指南
为什么需要 API Mocking？
当后端 API 尚未完成时，前端开发常陷入等待。WireMock 允许通过 mock 服务模拟真实 API 响应，支持前后端并行开发。例如使用 mock-json-generator 工具快速生成结构化的测试数据，无需依赖真实后端。
Towalles 提供的工具均运行在浏览器本地，确保敏感接口数据不会被上传到服务器。开发者可以安全地生成 mock 数据或 stub 规则，避免隐私泄露风险。
快速生成 WireMock Stub
使用 wiremock-stub-generator 工具，只需粘贴 Swagger/OpenAPI 文档或手动输入字段，即可自动生成 WireMock 的 JSON stub 配置。支持动态参数（如正则匹配路径）和条件响应，比手工编写效率提升 10 倍。
对于常见场景如分页查询或错误响应，工具提供预设模板。例如模拟 500 错误只需选择状态码，系统会自动补全符合规范的响应头和错误体结构。
契约测试实战技巧
将生成的 stub 文件放入 WireMock 的 mappings 目录，启动服务即可获得契约化的 mock API。通过 __files 目录存储对应的 mock JSON 响应文件，实现请求与响应的解耦管理。
建议为每个 API 版本创建独立目录结构。当后端接口变更时，通过 diff 工具比较新旧 stub 文件，可清晰识别契约变化点，避免联调时的意外中断。
动态响应与高级模拟
通过 Handlebars 模板实现动态响应：在 mock JSON 中嵌入 {{request.query.id}} 等变量，WireMock 会自动替换为实际请求参数。这对模拟分页数据或用户相关响应特别有用。
结合 Towalles 的 json-formatting-guide 工具验证生成的 mock JSON 合法性。浏览器本地处理机制保障了企业级 API 数据的安全性，特别适合敏感业务场景的开发调试。
把失败路径也桩出来
只做成功路径会藏住客户端缺陷。每个接口至少桩：典型 200、400 校验错误、401/403、404、带延迟的 500。响应用 json-formatter 格式化后入库，方便评审 diff。
从抓包到 stub
- 记录脱敏后的真实响应（按 pii 思路去掉密钥）。
- 统一 JSON 字段顺序与缩进。
- 生成 Wiremock 映射；匹配规则要收紧，过宽会吞掉无关请求。
- 在 CI 断言客户端处理各状态码。
什么时候不要 mock
需要真实厂商行为的契约（带签名的 webhook、古怪分页）应打沙箱集成测试。先用 hmac-generator、jwt-decoder 理解签名载荷，再决定哪些仍可桩。
模拟何时有用——以及何时掩盖缺陷
WireMock 类桩对 UI 开发与契约彩排很有用，但也会掩盖生产鉴权细节、分页边界与最终一致性。在桩目录旁维护一份「必须打到 staging」的流程清单。
桩的卫生习惯
- 按消费者场景命名，而不只按 path。
- Fixture 与所镜像的 API 版本一起编号。
- 失败即可见：本地 profile 对未知路由应明确 404。
本地工具闭环
用 json-formatter 生成桩 body、校验形态，再粘贴进 mock 配置。从网关日志复现精确 query 时用 url-encoder。
契约测试
把桩与消费者驱动的契约测试配对，避免 mock 在超过一个发布周期内静默偏离生产者 schema。
API Mock 治理
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。