Whistle Mock进阶：自定义响应头实现流式JSON数据精准模拟

1. 为什么流式JSON数据Mock会失败最近在做一个实时数据展示项目时遇到一个棘手的问题明明用Whistle成功Mock了接口返回的JSON数据但前端页面死活解析不出来。打开开发者工具一看数据确实返回了格式也没问题但页面就是显示空白。折腾了半天才发现原来是响应头Content-Type在作怪。这种情况在Mock流式JSON数据时特别常见。真实接口返回的Content-Type通常是text/event-stream而Whistle默认Mock返回的是text/plain。前端框架会根据Content-Type决定如何解析数据类型不匹配自然就解析失败了。这里有个常见的误区很多开发者以为只要数据内容对了就行忽略了响应头的重要性。实际上现代前端框架对响应头非常敏感特别是处理流式数据时。比如Vue的axios、React的fetch都会根据Content-Type选择不同的解析方式。2. 流式JSON数据的核心特征2.1 什么是流式JSON数据流式JSON和我们平时接触的普通JSON数据最大的区别在于传输方式。普通JSON是一次性返回完整数据而流式JSON是分批次持续传输。这种特性让它特别适合实时数据展示场景比如股票行情、实时监控、聊天消息等。从技术角度看流式JSON有这几个关键特征使用text/event-stream作为Content-Type数据以特定格式分块传输通常每个JSON对象单独成块保持长连接服务器可以持续推送新数据前端通过EventSource等API接收处理2.2 为什么需要特殊处理Mock这类接口时仅仅替换响应体是不够的。我曾经在一个物联网项目中需要Mock设备实时状态接口。按照常规方法配置后发现前端完全无法解析数据。后来用Chrome开发者工具对比真实接口和Mock接口的差异才发现问题出在响应头上。真实接口的响应头Content-Type: text/event-stream Cache-Control: no-cache Connection: keep-alive而Whistle默认Mock的响应头Content-Type: text/plain Cache-Control: max-age3600这种差异会导致前端采用错误的解析方式最终导致数据无法正常显示。3. 完整解决方案响应头响应体双配置3.1 准备Mock数据文件首先我们需要准备两个文件一个存放Mock数据一个存放响应头配置。这是我推荐的文件结构/whistle-values ├── mock-data │ ├── device-status.json │ └── device-headers.json └── rules在device-status.json中存放模拟的流式JSON数据。注意保持和真实接口相同的格式{ timestamp: 1634567890, status: normal, values: { temperature: 23.5, humidity: 45 } }3.2 配置自定义响应头接下来创建device-headers.json这里需要精确设置流式JSON所需的响应头{ Content-Type: text/event-stream; charsetutf-8, Cache-Control: no-cache, Connection: keep-alive, Access-Control-Allow-Origin: *, Transfer-Encoding: chunked }特别注意几点Content-Type必须包含text/event-streamCache-Control建议设为no-cache如果需要跨域要设置Access-Control-*相关头流式传输通常使用chunked编码3.3 编写Whistle规则现在我们可以编写完整的Whistle规则了。规则文件应该包含两部分# 设置响应头 https://api.example.com/device/status resHeaders://{device-headers.json} # 设置Mock数据 https://api.example.com/device/status file://{device-status.json}这里有个重要细节两条规则的URL必须完全一致包括查询参数而且响应头规则要放在数据规则前面。我曾经因为顺序问题调试了半天后来发现Whistle是按顺序匹配规则的。4. 高级技巧与常见问题排查4.1 动态生成响应头有时候我们需要根据请求动态设置响应头。Whistle支持通过函数动态生成headers// 在Values中创建dynamic-headers.js module.exports (ctx) ({ Content-Type: ctx.req.headers[accept] || text/event-stream, X-Request-Method: ctx.req.method, Cache-Control: no-cache });然后在规则中使用https://api.example.com/device/status resHeaders://{dynamic-headers.js}4.2 常见问题排查指南当Mock不生效时可以按照这个流程排查首先确认规则是否生效在Whistle的Network面板查看请求是否被拦截检查Rules面板是否有语法错误检查响应头是否正确对比真实接口和Mock接口的响应头差异特别注意Content-Type和Cache-Control验证数据格式确保JSON格式正确无语法错误流式数据要注意换行符和分隔符检查规则顺序确保没有其他规则覆盖当前规则复杂规则建议使用pattern operator://rule格式4.3 性能优化建议当Mock大量流式数据时可以考虑这些优化手段使用resMerge合并多个规则减少匹配开销对大文件使用file://引用而非直接内联合理设置缓存头避免不必要的重复传输考虑使用resScript动态生成数据减少存储占用我曾经Mock一个实时交易数据接口最初直接返回10MB的测试数据导致Whistle内存占用飙升。后来改用动态生成方案性能提升了80%。5. 真实项目中的应用案例去年在开发一个智能家居控制面板时我们需要模拟各种设备状态变化。通过Whistle Mock流式JSON数据前端团队可以独立开发不需要等待后端接口。具体实现方案创建设备状态变化序列// device-sequence.json [ {status:off,timestamp:1634567800}, {status:booting,timestamp:1634567810}, {status:ready,timestamp:1634567820}, {status:running,timestamp:1634567830} ]编写动态响应脚本// device-stream.js let index 0 const data require(./device-sequence.json) module.exports (ctx) { if (index data.length) index 0 return data[index] }配置Whistle规则# 流式设备状态 https://api.smarthome.com/device/stream resHeaders://{device-headers.json} resScript://{device-stream.js}这套方案让前端能模拟各种设备状态变化场景包括异常状态和边缘情况大大提高了开发效率。测试覆盖率从60%提升到了85%。6. 与其他工具的对比相比Postman、Charles等工具的Mock功能Whistle在流式数据Mock上有独特优势零延迟规则修改立即生效不需要重启服务细粒度控制可以精确到每个响应头字段动态能力支持JavaScript动态生成响应无侵入性不需要修改客户端代码不过它也有一些局限不适合复杂的业务逻辑Mock动态脚本调试不太方便大量规则时管理略显混乱在实际项目中我通常这样搭配使用Whistle负责接口格式Mock和简单逻辑Mock.js负责复杂数据结构和业务逻辑本地开发服务器提供完整的业务流程Mock这种组合既保证了灵活性又不会增加太多维护成本。特别是在前端需要独立开发的阶段能节省大量联调时间。