API请求经住宅代理返回204，应用随后报“JSON意外结束”。这可能是HTTP响应已完整完成，接着本地解码失败。把两件事合并成网络失败，容易让应用重复执行已经成功的操作。本文给授权集成团队一套分层验收流程，不代表98IP实测行为。
1. 解码前先确认端点约定
HTTP204表示请求成功且没有响应内容，并不保证存在JSON文档。空正文不是JSON的null，也不是空对象或空数组。Response.json会解析正文文本；不能解析为JSON时会产生SyntaxError。
向API负责人确认哪些方法和结果可返回204，哪些必须提供表示，以及什么应用证据能确认预期操作。记录端点版本、方法、最终目标和预期结果。不能为第三方API擅造占位对象。成功状态本身也不能证明选对了账号、资源或业务操作。
2. 传输证据和本地错误分开保存
在包装器改写结果前保存真实状态、非敏感响应头、跳转链及客户端传输异常。辨别是HTTP代理CONNECT响应，还是TLS内目标API响应。CONNECT成功不能证明目标业务结果，SOCKS协商也是另一层。
比较响应完成时间和JSON失败时间，记录客户端版本、解码策略、关联ID及实际方法。已经观察到完整204时，不要把本地解析错误标为代理超时。没有完整响应或轨迹缺失则保留未知，不能由零字节推造一个204状态。
3. 用三种独立自有夹具对照
- 选择负责人批准的预发布端点，不产生真实订单、支付、通知或删除。每次有独立日志关联及固定预期。
- A返回合法204且无响应内容，客户端应进入约定的无正文成功分支，不调用JSON解析，也不创造替代载荷。
- B返回200及负责人指定的小型有效JSON标记，确认正常解码和精确标记校验仍可用。
- C故意违反约定，例如要求JSON却返回200空正文。它应保持解码或契约失败，不能静默按204接受。
- 在获准基准与指定代理路径运行同例，固定客户端、目标、账号状态和解码配置；核对真实出口及稳定会话策略。
限制尝试次数，既记录库内自动重试，也记录应用层尝试。三种夹具均选择正确分支才通过。未获准直连则注明缺少基准，不能为补齐矩阵向公共服务制造传输异常或畸形响应。
4. 修分发规则，不抹掉错误证据
自有客户端应按已约定的状态和端点规则分发，再决定调用何种解码器，并明确表示无正文成功。应有JSON的响应仍需解析和模式校验，不能捕获所有解析错误后返回空对象。若中间件先消耗了响应流，也应另查，不能把全部解码错误都叫空正文。
自有服务的204不得带响应内容或Content-Length头。不能为了满足客户端而加空JSON对象，同时仍返回204。契约若需要表示，应由负责人明确调整响应和客户端。保留实际协议不符证据，因为浏览器视图可能隐藏被丢弃字节。
- 完整204后JSON失败：查解码选择及包装器无正文处理。
- 200但约定JSON缺失：保留错误，查响应生成方或契约版本。
- 响应未完整结束：单独查传输和操作状态，零字节不能确定状态码。
- 204正确但界面一直转圈：查应用完成状态与独立确认，不只看解析。
5. 别让本地解码失败重复成功写入
完整响应后的解码错误不能自动把操作重置为“未发送”。既有写入集成应先按负责人支持的状态查询或读回机制核对，再决定人工重提。按服务幂等规则保留原操作身份，不为强行重试新建幂等键。
读回本身有独立授权、新鲜度和错误处理；读回失败不证明原写入失败。结果仍不明时停止写入循环并标未知，可参阅POST超时与重复提交指南。用无害夹具测分发，不重放真实客户交易。
6. 路径控制与验收清单
授权地区API测试需要住宅路径时，查看98IP动态住宅IP产品页，依配置文档及账号支持参数接入。先固定客户端约定，再核对出口，逐条比较路径。
代理不会替204制造JSON表示，也不保证业务结果。普通未拦截HTTPS代理不能改写加密目标载荷。限定请求和流量、查看账号用量，证据排除密码、Cookie和客户资料。本文不承诺实测吞吐、兼容性或计费结果，也不授权绕过目标控制。
- 端点方法、版本和允许的无正文结果已确定。
- 目标响应完成、CONNECT及本地解码错误分别记录。
- 合法204、合法200JSON及缺失必需JSON走不同分支。
- 无正文成功不解析JSON、不创造载荷。
- 要求表示的端点仍明确暴露缺失或错误。
- 未知写入先核对，不因解析异常反复提交。
204证明代理删除JSON了吗？ 不能，先查端点是否本来无正文及轨迹是否完整。
所有空正文都算成功吗？ 不是，要求JSON的200端点仍必须满足约定。
换IP能修解码吗？ 不会修正分发规则，应固定路径复现客户端行为。