WireMock启动失败因端口占用或未用standalone jar；单元测试404因未调用stubFor或configureFor；中文乱码需显式设UTF-8编码；多响应需用queryParam或matchingJsonPath精准匹配。
WireMock 启动失败：端口被占或找不到 standalone jar
WireMock 默认以独立模式运行，但新手常卡在启动这一步。不是 Java 环境问题，而是没搞清它依赖哪个 jar 包、怎么指定端口。
- 必须用官方发布的
wiremock-jre8-standalone-x.x.x.jar（注意带-standalone），普通wiremock主包不能直接 java -jar 启动 - 启动命令里不加
--port就默认 8080，如果报Address already in use，要么改端口：java -jar wiremock-jre8-standalone-1.6.0.jar --port 9090，要么先lsof -i :8080（mac）或netstat -ano | findstr :8080（win）杀掉进程 - 别把
wiremock-standalone和wiremock-core混用——后者是库，得写代码集成，不是拿来直接跑的
Java 单元测试中集成 WireMock：为什么 WireMockServer 启动后请求仍 404
这是最典型的配置遗漏：WireMock 默认只响应匹配的 stub，但没显式启用「动态映射」或没调用 stubFor，所有请求都会 fallback 到 404。
- 用
WireMockServer时，必须手动调用configureFor("localhost", port)，否则它会按默认 host:port 发起反向请求，而不是监听 - 每个 mock 接口都要显式定义，比如
stubFor(get(urlEqualTo("/api/user/123")).willReturn(aResponse().withBody("{\"id\":123}")))；漏掉stubFor或路径写错（比如少个/）就 404 - 测试结束后记得
wireMockServer.stop()，否则下次 test 可能因端口冲突失败，尤其用 Maven 并行执行时
JSON 响应体中文乱码：WireMock 返回 \u5b57\u7b26\u4e32 而不是正常汉字
WireMock 默认用 ISO-8859-1 编码解析响应体字符串，遇到中文就转义成 Unicode。这不是 bug，是配置缺失。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 响应体必须显式指定编码：
withBody("{\"name\":\"张三\"}").withHeader("Content-Type", "application/json; charset=utf-8") - 如果用 JSON 文件做响应（
withBodyFile("user.json")），确保该文件本身是 UTF-8 编码保存，且编辑器没偷偷存成 UTF-8 BOM - Spring Boot 项目里若用
@AutoConfigureWireMock，需额外加@TestConfiguration注册WireMockConfiguration并设charset = "UTF-8"，否则注解方式也乱码
Mock 多个不同响应：如何让同一 URL 根据请求参数返回不同 JSON
WireMock 支持条件匹配，但语法容易写错。重点不是“能不能”，而是“怎么写才不被忽略”。
立即学习“Java免费学习笔记（深入）”；
- 用
queryParam匹配 GET 参数：get(urlPathEqualTo("/search")).withQueryParam("q", equalTo("java"))；注意urlEqualTo是全路径匹配，urlPathEqualTo才忽略 query string - POST 请求体匹配要用
withRequestBody+matchingJsonPath，比如matchingJsonPath("$.email", equalTo("test@example.com"))；直接用equalTo匹配整个 body 容易因空格、换行失败 - 多个 stub 冲突时，WireMock 按注册顺序匹配第一个成功项，所以更具体的规则（如带 query param）要放在前面，泛化规则（如只匹配 path）放后面
WireMock 的坑不在功能弱，而在默认行为太“安静”——不报错、不提示、不 fallback，只默默返回 404 或空响应。调试时第一反应不该是“是不是代码错了”，而是打开 __admin/requests 看实际进来的请求长什么样，再比对 stub 规则是否真命中。
