接口返回 204 却报 JSON 解析错，怎样处理没有响应体

204 No Content没有响应内容，客户端应按状态码进入无body分支，不能无条件调用JSON解析。空字节也不是JSON null：null是四个字节的合法JSON文本。正确处理204只能确认HTTP层的成功语义，设备是否达到目标状态仍取决于接口合同和后续状态回读。

环境和证据范围

本文比较204空体、200空体与200合法JSON的离线样本，不读取真实网络流。200空体在HTTP中不必然非法，但若该资源文档承诺JSON对象，客户端应报告契约缺失。这里的判断以明确的“200必须提供JSON对象”样例契约为前提。

核对顺序

1. 先将状态码、Content-Type和body字节数独立记录，别只记录解析异常文本。空字符串、只有空白、JSON null和空对象都是不同输入，调试界面可能把它们显示得很接近。

2. 对204直接走无内容分支，返回无body结果。若底层交出了不该有的字节，应报告协议异常并调查服务端或中间件，不能为了绕过异常把内容强行作为业务值。

3. 对文档要求JSON的200再做解析，区分空体、非法JSON和类型不符。空对象虽然能解析，也可能缺少业务字段；类型检查和字段检查应分成独立步骤。

4. 错误日志要保留状态和body长度，敏感内容仅保存脱敏片段。若统一HTTP封装把所有2xx都立刻解析成JSON，应在封装层建立状态与资源契约的分派，而不是给每个按钮临时加异常捕获。

可复算的输入与预期

附件预期依次为：204+空字节→无内容；200+空字节→缺少JSON；200+{“ok”:true}→有效对象；200+null→类型不符；204+{}→协议异常。脚本实际解析五个样例，并明确bool不能替代对象结构。

下载与现场记录

下载本题合成输入与预期JSON、离线只读核验脚本和现场空白记录CSV。放在同一目录，用 Python 3 运行 python verify.py，逐项计算或解析后与预期比较，失败会显示差异。

现场字段包括 status、content_type、body_bytes、parse_branch、business_fields、readback。合成样例保持原样，实测另存并填写型号、版本、证据路径，未采集处留空。本地核验不代表真实设备、代理、浏览器或长期稳定性已测。

失败分支与移交

catch解析异常后直接返回成功，会把服务端故障HTML或截断JSON一起掩盖。把200空体全部当204同样危险，会丢失文档要求的状态值。若状态码不稳定，先向接口方确认资源契约，不能从一次成功样本推导所有设备固件行为。

移交时附每个操作预期的成功状态码与是否有body，记录合法响应类型、缺字段处理和设备回读方法。真实设备的204是否遵守规范、HTTP库是否保留异常字节、网络中间件是否改写响应均未测，现场应按同一矩阵采样留证。

基础背景可看HTTP / RESTful 设备控制接口科普。304同样不能把空体当新数据，但处理依据不同，见轮询状态遇到 304，怎样用 ETag 保留正确的本地副本。更多资料在设备协议库。

需要接入中控时，可对照SoftControl设备联动需求核实适配范围；独立校验方法是否纳入交付需逐项约定。

一级资料

• 官方资料：§15.3.5 204不含内容；与§6.4消息内容边界

核对日期：2026-10-24。规范定义与本文应用约定分开，示例门限及脚本不自动代表产品原生能力。