简介通过部署在Tomcat上的war包即可搭建一套可自定义的HTTP响应模拟服务面向前后端开发与测试人员用于在后端未就绪或需要异常场景时快速返回预设报文例如模拟500错误、延迟响应或特定响应头。资源以rar压缩包形式提供共45个文件大小约7.25MB其中包含可直接运行的war包、23个class、14个jar以及xml、properties等配置说明既能直接启动使用也为理解实现和二次开发留出空间。已有883人学习下载。工具支持按URL、请求方法等条件匹配可自定义状态码、响应头与响应体覆盖开发联调、自动化测试、性能压测及故障注入等场景。借助这份资源可摆脱对外部服务的依赖快速验证前端逻辑或为测试框架提供稳定mock环境同时可从class与jar结构中了解实现思路便于自行扩展响应规则。1. 模拟报文返回工具不是黑匣子它解决的是联调与测试的等待问题后端接口还在开发前端已经把请求逻辑写好了测试想看一眼接口超时和 500 页面真实服务却一直正常第三方接口偶尔抽风问题却没法稳定复现——这些场景凑到一起就是 Http 请求模拟报文返回工具要解决的事。它本质上是一个按你给的规则“假装成后端”的 HTTP 服务收到请求后不做任何业务处理直接把预先配置好的状态码、响应延迟和报文体返回给调用方。前端拿它做联调测试拿它造异常场景后端拿它验证自己的容错逻辑。这篇笔记我会从选型讲到一个能直接抄走的 Mock 服务实现并把模拟报文返回里常见的坑一并交代清楚争取让新手能照着落让熟手能避开我踩过的那些坑。2. 模拟报文返回的三种路线自建 Mock 服务、WireMock 与抓包改包怎么选2.1 模拟报文返回的本质是一个“假后端”一个 HTTP Mock 服务不管包装成什么样骨架都逃不过三层请求入口、路由匹配器、响应模板。请求进来后先看 HTTP 方法和 URL 路径能不能匹配上某条规则匹配上就按规则拼装状态码、响应头和报文体匹配不上就返回 404或者把请求转发到真实服务。所谓模拟报文返回就是把业务处理替换成“查规则、吐预设报文”这两个动作。这个骨架想清楚之后后面所有工具都只是这三层的不同实现方式WireMock 把规则写进 JSON 文件Mockoon 把规则放在图形界面的节点里自建 Express 服务把规则写成路由函数。选工具的本质就是看这三层里哪一层的表达方式最贴合你的真实场景。我见过不少人在选型时纠结工具界面好不好看其实不关键关键就三件事能不能按方法和路径区分响应能不能按请求参数动态吐不同报文能不能把没匹配的请求转发给真实服务。2.2 三条主流路线的取舍自建脚本、WireMock 与抓包改包第一条路线是自己写脚本。常见做法是用 Node.js 加 Express或者 Python 加 Flask几十行代码就能撑起一个具备基本能力的 Mock 服务。好处是规则完全可控能进 Git 仓库跟着项目走也能做很复杂的动态逻辑——比如根据请求 body 查数据库、调用别的内部服务再决定返回什么。坏处也明显要有人维护代码依赖一多新人上手就慢。第二条路线是专用 Mock 工具代表作是 WireMock。WireMock 是 Java 生态的独立进程stub 规则写在 JSON 文件里请求匹配器比手写路由强不少支持 URL 正则、Header 匹配、Body Pattern 匹配还有录制模式可以把真实服务的响应录下来再回放。典型的一条 stub 长这样{ request: { method: GET, urlPathPattern: /api/user/([0-9]) }, response: { status: 200, jsonBody: { code: 0, data: { id: {{request.pathSegments[1]}}, role: admin } }, headers: { Content-Type: application/json } } }这里的{{request.pathSegments[1]}}就是模板变量能把请求路径里的用户 ID 动态填进响应报文里。WireMock 适合在测试环境长期跑还支持用 Scenario 做状态流转——比如第一次请求返回“待支付”第二次返回“已支付”这对联调支付流程特别有用。缺点就是 Java 进程相对重改规则要改 JSON、重启服务新人上手有一道门槛。还有个桌面工具 Mockoon属于第三条路线里比较讨喜的一种带 GUI左边选请求方法和路径右边填状态码、响应头和 body支持 Handlebars 模板变量和一键模拟延迟。个人开发调试非常舒服缺点是配置存在本机团队共享要靠手工导出 JSON 文件版本一多容易乱。抓包改包工具比如 Charles、Fiddler 也常被拉来当 Mock 用。它们本质是代理可以在断点处修改请求或响应适合排查线上既有接口的问题。但它是改流量不是定义接口配置只在一台机器上生效没法作为团队的 Mock 基线。方案适合场景团队共享动态能力学习成本自建 Express/Flask小组联调接口字段频繁改强规则进 Git强逻辑随便写中要写代码WireMock测试环境长期运行需要录制回放中JSON 规则可入库强匹配器丰富中高Java 生态Mockoon个人开发快速造一个假接口弱靠导出文件中支持模板变量低纯 GUICharles/Fiddler复现线上问题改单次流量弱本机配置中断点能改包低2.3 我的选型口径谁用、用多久、要不要状态流转我一般会先回答三个问题再决定上哪条路。第一谁要用只有一个人在调试直接上 Mockoon十分钟把接口拖出来。一个小组成员都要连同一个假后端那就自建服务放进项目仓库前端 clone 下来一条命令跑起来。第二用多久联调结束就扔别上重工具要在测试环境稳定跑几个月WireMock 的录制和状态流转能力才值回它的学习成本。第三要不要状态流转接口有“未支付→已支付”这种多状态场景自建脚本写分支要费点劲WireMock 的 Scenario 反而是现成的。这里有个反面案例值得说。之前有个项目组统一上了 WireMock规则文件写了两千多行结果后端接口一改路径前端找不到对应的 stub排查半天才发现是规则没同步。原因是团队里没人专职维护 Mock大家都觉得“能跑就行”。后来我把那套东西换回一个不到一百行的 Express 服务路由就是函数接口变更直接改代码问题反而少了。所以我的习惯是默认先从自建服务开始等确认需要长时间运行、需要复杂匹配再迁移到 WireMock 这类专业工具。不要一上来就上重工具也不要一开始就追求字段级动态大多数联调只需要固定报文加三五个分支。3. 用 Node.js 把第一个“模拟报文返回”跑通Express 最小实现与验证3.1 一个能直接抄走的最小服务先建一个目录初始化 npm 并安装 express然后新建 mock-server.jsmkdir mock-demo cd mock-demo npm init -y npm install express// mock-server.js一个最小的 Http 请求模拟报文返回服务 const express require(express); const app express(); // 解析 application/json 请求体后面 POST 接口要用 app.use(express.json()); // 端口支持环境变量传参方便 CI 里切换 const PORT process.env.PORT || 3000; // 第一个 mock 路由按用户 id 返回固定报文 app.get(/api/user/:id, (req, res) { res.json({ code: 0, data: { id: req.params.id, name: 测试用户, role: admin } }); }); // 兜底 404前端一眼能看出哪个接口没配 mock app.use((req, res) { res.status(404).json({ code: 404, message: no mock for ${req.method} ${req.path} }); }); app.listen(PORT, () { console.log(mock server ready at http://localhost:${PORT}); });启动命令就一行node mock-server.js3.2 代码逻辑与参数说明这段代码里最容易忽略的是app.use(express.json())。没有这一行POST 请求带 JSON body 进来时req.body是undefined后面做动态分支直接报错这是新手最常见的第一个翻车点。res.json()会自动设置Content-Type: application/json; charsetutf-8中文不会乱码这也是我坚持用res.json()而不是res.send(JSON.stringify(...))的原因。路由里的:id是 Express 的路径参数访问/api/user/1时req.params.id就是字符串1。如果把 id 当成数字处理记得先parseInt否则拼接 SQL 或做判断时容易踩类型坑。末位的兜底 404 中间件必须放在所有 mock 路由之后它的作用是让前端开发者立刻知道“这个接口没被 Mock”而不是对着一个诡异的状态码猜半天。参数默认值说明PORT3000Mock 服务监听端口CI 里用环境变量覆盖路由路径按需定义必须和前端请求的 method、path 完全一致响应报文固定 JSON改动后不需要重启依赖的框架但 node 进程要重启才生效这里我特意没上 nodemon 之类的热重载因为 Mock 服务本身要的就是“确定性”改了要重启反而是个优点至少你不会对着旧报文排查半天还以为代码没生效。3.3 用 curl 和 axios 验证返回报文服务启动后先开一个终端验证响应curl -i http://localhost:3000/api/user/1重点看两个地方响应头是否包含Content-Type: application/json; charsetutf-8响应体是不是预期的 JSON。如果返回的是 HTML 报错页基本就是路由没匹配上走了兜底逻辑。前端侧用 axios 验证更直接。很多项目里前端请求已经封装好了联调时只需要把 axios 的 baseURL 指到 Mock 服务// 联调阶段baseURL 指向 mock后端 ready 后换成真实地址 const res await axios.get(http://localhost:3000/api/user/1); console.log(res.data.data.name); // 输出测试用户axios 的 GET 请求默认会带 query 参数比如axios.get(/api/user/1, { params: { debug: 1 } })你会发现 Mock 服务根本不用管这个参数因为路由只匹配路径。这个特性后面做动态报文时很有用——你可以在 query 里塞控制参数Mock 服务按参数决定吐什么报文前端代码不用动。3.4 不想写 NodePython Flask 的等价实现团队技术栈是 Python 的话Flask 版本同样干净# mock_server.pyPython 侧等价实现 from flask import Flask, jsonify, request import os app Flask(__name__) app.route(/api/user/int:user_id, methods[GET]) def get_user(user_id): return jsonify(code0, data{ id: user_id, name: 测试用户, role: admin }) if __name__ __main__: app.run(host0.0.0.0, portint(os.environ.get(PORT, 3000)))pip install flask python mock_server.pyFlask 的jsonify跟 Express 的res.json()一样会自动带上application/json; charsetutf-8。int:user_id直接把路径参数约束成整数比 Express 的字符串参数更省心。Node 和 Flask 怎么选我只看一个标准团队里谁接手维护最快。前端团队为主就选 Node后端自动化团队为主就选 Flask别在这个选择上纠结架构先进性。4. 让 Mock 响应“活”起来状态码、延迟、动态模板与代理转发4.1 用全局中间件模拟延迟与服务端异常固定报文只能满足最基础的联调真正让 Mock 工具产生价值的是模拟异常场景。先在路由之前加一个延迟中间件让所有接口都能按参数模拟网络耗时// 延迟中间件优先读 query 里的 _delay没传就用环境变量 const MOCK_DELAY Number(process.env.MOCK_DELAY || 0); app.use((req, res, next) { const delay Number(req.query._delay) || MOCK_DELAY; if (delay 0) { return setTimeout(next, delay); } next(); });用法很简单curl http://localhost:3000/api/user/1?_delay3000响应会延迟 3 秒返回。这里有个必须提醒的点延迟时间一旦超过前端 axios 或浏览器默认的 timeoutMock 就会被判定为超时前端拿到的是网络错误而不是响应报文。所以模拟超时场景有两种做法要么把延迟设得比 timeout 大专门给前端看超时表现要么设得比 timeout 小给后端看慢请求下的表现。别一个值走天下。服务端异常的模拟用 POST 接口演示按请求 body 里的字段决定返回 500 还是正常报文// 模拟服务端异常前端传 typeerror 就返回 500 app.post(/api/order, (req, res) { if (req.body.type error) { return res.status(500).json({ code: 500, message: 模拟服务端异常 }); } res.json({ code: 0, data: { orderId: Date.now() } }); });4.2 按请求参数返回不同报文query、body 与路由参数模拟工具区分“玩具”和“可用”的分水岭就是看它能不能按请求参数动态返回。上面的 POST 接口已经按req.body.type做了分支再补一个按 query 控制返回列表还是空数据的例子// 按 query 参数返回不同报文empty1 时给空列表 app.get(/api/order/list, (req, res) { if (req.query.empty 1) { return res.json({ code: 0, data: [] }); } res.json({ code: 0, data: [ { orderId: 1001, amount: 19.9 }, { orderId: 1002, amount: 29.9 } ] }); });前端用 axios 的 POST 请求触发异常分支const r1 await axios.post(http://localhost:3000/api/order, { type: error }); console.log(r1.status); // 500这种“同一个接口、按参数吐不同报文”的模式是前后端联调里最高频的诉求。后端说“我需要三种响应成功、参数错误、服务异常”你就给对应三个分支前端把三种情况都跑一遍比等真实后端全做完了再测要快得多。注意分支条件要保持简单别在 Mock 里写复杂业务判断Mock 是用来模拟行为的不是用来重新实现一遍业务的。4.3 Content-Type 与报文格式JSON、XML 与表单的分歧Http 请求模拟报文返回工具最常见的翻车点之一就是响应 Content-Type 和调用方预期不一致。JSON 接口用res.json()没问题但遇到 XML 报文就会出岔子// 返回 XML 报文必须显式指定 Content-Type否则会被当纯文本解析 app.get(/api/report, (req, res) { res.type(application/xml); res.send(reportstatusok/statusts2025-01-01/ts/report); });这里必须用res.send()传字符串再用res.type(application/xml)设置响应头。有些 SDK 是按 Content-Type 决定怎么解析响应体的你返回的是 XML 文本却带着application/json对方解析直接抛异常而且这种问题在浏览器里看不出来只有看响应头才能定位。表单格式同理// 返回 urlencoded 表单格式报文 app.post(/api/form, (req, res) { res.type(application/x-www-form-urlencoded); res.send(code0messageok); });这类接口的调用方通常不是浏览器页面而是其他后端服务。它们的 HTTP 客户端对 Content-Type 极其敏感所以 Mock 服务的响应头必须和真实后端保持一致。我验证时习惯用curl -i看完整响应头而不是只看 body 好不好看。4.4 匹配不到的请求转发给真实服务代理模式收尾Mock 服务和真实后端共存是团队联调阶段的理想状态。实现方式是给 Mock 服务加一层反向代理所有没被 mock 路由匹配的请求直接转发到真实后端// 安装npm install http-proxy-middleware const { createProxyMiddleware } require(http-proxy-middleware); // 真实后端地址用环境变量控制 const PROXY_TARGET process.env.PROXY_TARGET || ; // 这段要放在所有 mock 路由之后 if (PROXY_TARGET) { app.use(/api, createProxyMiddleware({ target: PROXY_TARGET, changeOrigin: true // 后端校验 Host 时改成目标域名 })); }启动时指定 PROXY_TARGETMock 服务就成了一个“优先假数据、兜底真服务”的网关。后端某个接口还没开发完Mock 路由先顶上开发完的接口请求自动转发到真实服务前端无感知。changeOrigin这个参数很容易被忽略真实后端如果校验了 Host 头不加它会被拒加了才能伪装成同域请求。这个模式尤其适合接口列表特别多、只有个别接口需要 Mock 的项目。5. 常见问题避坑模拟报文返回里最容易翻车的 5 个现场模拟报文返回的工具本身不复杂复杂的是把它放进真实联调环境后出现的一堆“玄学”。下面这些现场是我在这些工具上反复见到的按出现频率排序每一条都按现象、原因、解决三个步骤拆开讲。5.1 中文变成 \uXXXX 或乱码现象接口返回的 JSON 里华人名变成\u6d4b\u8bd5前端拿到后能正常显示但测试用 curl 看报文满屏转义符以为服务端编码出了问题。原因这其实分两种情况。一种是res.json()的默认转义行为把非 ASCII 字符转成\uXXXX这是 JSON 规范允许的前端JSON.parse后自动还原不算 bug。另一种才是真问题——如果用了res.send(JSON.stringify(obj))且没设 charset响应头可能只有Content-Type: application/json浏览器会按默认字符集解码中文就成乱码。解决统一用res.json()它会自动带charsetutf-8。如果非要手动拼 JSON 字符串就显式设置res.set(Content-Type, application/json; charsetutf-8)。看到\uXXXX别慌先看响应头有没有 charset有就放心。5.2 浏览器报 CORSaxios 请求发不出去现象前端页面跑在localhost:8080Mock 服务在localhost:3000打开控制台看到blocked by CORS policyaxios 的 GET、POST 全被拦。原因跨域策略在浏览器侧生效不是 Mock 服务拒绝请求而是浏览器没拿到允许跨域的响应头。尤其是 POST 请求带Content-Type: application/json时会先发 OPTIONS 预检Mock 服务没处理这个预检请求就死在半路。解决给 Mock 服务套一个 CORS 中间件。不引包手写也简单// 手写 CORS 中间件放在所有路由最前面 app.use((req, res, next) { res.set(Access-Control-Allow-Origin, *); res.set(Access-Control-Allow-Methods, GET,POST,PUT,DELETE,OPTIONS); res.set(Access-Control-Allow-Headers, Content-Type,Authorization); if (req.method OPTIONS) { return res.sendStatus(204); } next(); });这段代码处理了两个关键点返回允许跨域的响应头以及对 OPTIONS 预检直接回 204。Access-Control-Allow-Origin如果不想全放开可以换成具体的前端地址但 Mock 场景用*最省事。5.3 路由顺序的坑参数路由把精确路由“吃”掉了现象配置了/api/user/:id之后又加了一个/api/user/list的列表接口结果前端访问/api/user/list返回的id字段是字符串list列表数据一直拿不到。原因Express 的:id是通配参数能匹配任意非空路径段。注册顺序靠前的参数路由先被命中list被当成 id 值填进去了。解决精确路由永远放在参数路由前面。// 写在前面的是精确路径 app.get(/api/user/list, (req, res) { res.json({ code: 0, data: [] }); }); // 参数路由写在后面 app.get(/api/user/:id, (req, res) { res.json({ code: 0, data: { id: req.params.id } }); });还有个加固办法给参数路由加正则约束只匹配纯数字app.get(/api/user/:id(\\d), ...)。这样list永远进不了参数路由顺序错了也兜得住。5.4 http 连接复用导致改端口后前端还连旧服务现象Mock 服务从 3000 端口换到 3001重启后前端刷新页面请求全部失败控制台报的地址还是localhost:3000。原因axios 在浏览器端会复用 keep-alive 连接池里同一个 host 的 socket。http 连接复用本意是减少握手开销但在 Mock 调试阶段就成了坑——端口变了连接池里还握着旧 socket前端进程不重启就一直在打旧地址。解决改端口后必须重启前端进程或者彻底刷新页面让连接池清空。更稳的做法是 Mock 端口固定不变只通过环境变量传入。我最开始在多个项目里用过随机端口排查过两次这个问题后统一改成固定端口环境变量只在 CI 里用。5.5 端口被占用EADDRINUSE 与“请求的资源在使用中”现象启动node mock-server.js直接报EADDRINUSEWindows 上偶尔会提示“请求的资源在使用中”。本人遇到过最离谱的一次是 CtrlC 没把 node 进程杀干净旧进程还占着 3000。原因端口被残留进程或另一个服务占用。Windows 的提示更容易误导人看着像文件锁其实是 socket 端口没释放。解决先查端口再杀进程。Linux 和 macOS 用lsof -i:3000拿 PID然后kill -9。Windows 用netstat -ano | findstr :3000 taskkill /PID 进程号 /F如果只是临时起 Mock也可以直接把启动命令改成备用端口PORT3001 node mock-server.js但改端口后要记得同步 5.4 那条前端 baseURL 跟着改。6. 落地为团队共享的 Mock 服务环境变量开关、Docker 镜像与接口冒烟验证让模拟报文返回工具真正有威力的地方不是个人电脑而是每个前端 clone 下项目后一条命令就能把假后端跑起来。做法是把 mock-server.js 和 package.json 放进仓库启动命令的环境变量全部留好MOCK_PORT控制端口MOCK_DELAY控制全局延迟PROXY_TARGET控制是否转发真实后端。我自己会配一个 npm script比如npm run mock统一入口比让大家记node mock-server.js靠谱。上线前写个冒烟脚本能省掉不少“明明改了 Mock 却说没生效”的扯皮。思路是对核心路由各请求一次检查状态码和关键字段#!/bin/bash # mock 冒烟验证核心路由按预期返回 BASE${BASE_URL:-http://localhost:3000} code$(curl -s -o /dev/null -w %{http_code} $BASE/api/user/1) [ $code 200 ] || echo user 路由失败: $code curl -s -X POST $BASE/api/order \ -H Content-Type: application/json \ -d {type:error} | grep -q code:500 || echo error 分支失败这个脚本丢进 CIMock 服务每次改动后自动跑一遍比人肉检查快得多。要发布成团队镜像也简单基于node:18-alpine构建先把 package.json 复制进去装依赖再复制源码利用 Docker 的层缓存能省一大半构建时间运行端口映射到 3000环境变量照常传。我自己现在做前后端联调的第一步永远是先把这个 Mock 服务从旧项目里拷过来按新接口改路由再让前端指向它。等真实后端 ready 了只改一个环境变量就切回去前端代码一行不用动。这套流程不惊艳但它让我在联调阶段少和后排同学扯皮也让我敢在发布前放心重构接口——Mock 就是我的后悔药。希望这套模拟报文返回的落地方式能帮到你。本文还有配套的精品资源点击获取