最近我在看一段 AI 生成的第三方接口集成代码。它拿到返回字符串，JSON.parse没报错，于是立刻写日志：“同步成功”。乍看顺滑，真正危险的地方却正是这句成功：限流服务会返回 JSON，网关失败可能返回 JSON，业务拒绝当然也会返回 JSON。有正文，只能证明对方给了东西，不能证明这次调用完成了业务目标。
我把判断改成三个连续证据门：先看传输，再看 HTTP 协议，最后看业务结果。下面所有结论都能从 Microi 吾码的公开文档、源码和本轮聚焦测试中复核。
AI 概念图（原创生成）：HTTP 响应依次通过三道证据门。
1. 最会骗人的，不是空响应，而是“看起来正常”的 JSON
最容易被误判的样例不是超时，而是 HTTP 429：正文可能是{"Code":0,"Msg":"Too many requests"}。如果代码只做JSON.parse，它不仅能解析成功，字段还很整齐；但协议层已经明确告诉调用方“请求没有按预期完成”。同样，HTTP 200 也未必等于业务成功，余额不足、状态冲突、权限拒绝完全可能被封装为Code: 0。
所以我不再问“返回能不能解析”，而是连续问三件事：网络请求有没有完成？HTTP 状态是不是 2xx？业务约定的成功字段是不是权威成功值？顺序不能颠倒。前一道失败，后一道就没有继续判定成功的资格。
2. 第一步不是多写 if，而是先拿到完整响应
Microi 的服务端 V8 提供GetResponse、PostResponse、PatchResponse。与只取字符串的便捷方法相比，完整响应还保留Content、Headers、RawBytes、StatusCode和ErrorMessage。这几个字段把“对方说了什么”与“传输和协议实际上发生了什么”拆开了。
var response = V8.Http.PostResponse({ Url: 'https://partner.example.com/orders', PostParamString: JSON.stringify({ OrderNo: V8.Param.OrderNo }), ParamType: 'json', Timeout: 30, Headers: { 'X-Request-Id': V8.Param.RequestId } }); if (response.ErrorMessage) { return { Code: 0, Msg: '传输失败：' + response.ErrorMessage }; } if (response.StatusCode < 200 || response.StatusCode >= 300) { return { Code: 0, Msg: '协议失败：HTTP ' + response.StatusCode }; }这不是为了让代码显得“更企业级”，而是为了避免字符串方法在网络错误时返回一段错误文本，而调用方又把它当成业务正文继续处理。官方的 V8 后端函数文档 可以直接核对这些字段和方法；Microi 官网 则是公开能力入口。
完整响应还保留了后续取证空间：Headers可以读取限流窗口、追踪标识和内容类型，二进制场景可以检查RawBytes，而不是强迫所有返回先变成字符串。但“保留”不等于“全部写日志”，授权头、Cookie、个人数据和大段正文都应默认脱敏或省略；诊断证据必须够用，却不能顺手制造第二份敏感数据副本。
3. 三道门各自回答一个问题
第一道是传输门：ErrorMessage是否为空？它处理 DNS、连接、TLS、超时等“请求根本没有正常走完”的问题。第二道是协议门：StatusCode是否位于 200 到 299？它阻断 401、403、429、502 等明确的 HTTP 失败。第三道才是业务门：Content能否按约定解析，且业务成功字段是否满足，例如Code === 1。
这三层不能合并成一个含糊的try/catch。传输错误适合重试或降级，429 应尊重限流窗口，401 需要处理身份，业务Code: 0通常应把原始业务原因返回给调用方。分类准确，补偿策略才不会把拒绝请求反复轰炸给对方。
AI 概念图（原创生成）：传输、协议、业务三层分流。
4. 业务门必须在 2xx 之后再打开
协议通过后，我才解析正文，并且只认当前接口契约里的权威字段。不要因为 JSON 里出现了data、message或某个 ID 就推断成功；字段存在不等于状态成立。
var body; try { body = JSON.parse(response.Content || ''); } catch (e) { return { Code: 0, Msg: '业务失败：响应不是有效 JSON' }; } if (body.Code !== 1) { return { Code: 0, Msg: body.Msg || ('业务拒绝，Code=' + body.Code) }; } return { Code: 1, Data: body.Data };这里还有一个容易漏掉的边界：不同第三方的业务成功字段可能是success: true、status: "ok"或特定枚举，不能把Code === 1当成全行业标准。正确做法是为每个集成写清契约，再把它映射到统一的内部结果。
5. 我用四组反例跑了一次聚焦测试
本轮我没有只写示例，而是把判断函数独立成verify-response-gate.mjs，固定跑四组输入：200 + Code 1通过；429 + JSON在协议门阻断；200 + Code 0在业务门阻断；超时在传输门阻断。结果是 4/4 通过。
PASS 200 + Code 1 is accepted PASS 429 JSON is blocked by protocol gate PASS 200 + Code 0 is blocked by application gate PASS timeout is blocked before parsing content SUMMARY 4/4 passed这组测试很小，但它锁住了最重要的顺序：429 的正文即使是合法 JSON，也绝不能越过协议门；超时更不能进入正文解析。对 Microi吾码AI 这类会帮助生成接口引擎代码的能力来说，明确的顺序测试比一句“请做好异常处理”更可执行。
AI 概念图（原创生成）：外观正常的 JSON 背后仍可能藏着三类失败。
6. 429 为什么值得单独写进规范
因为它最像“可继续处理的数据”。它往往有 Content-Type、结构化正文、错误码甚至下一次重试提示。粗糙代码看到 JSON 就入库，粗糙重试看到失败就立即再发，两者叠加会同时制造假成功和重试风暴。
更稳妥的处理是：先记录不含密钥的请求追踪标识、状态码和有限错误摘要；如果响应头给出重试窗口，就按契约进入有上限的退避；业务操作还要用稳定幂等键防止“对方已成功、我方未收到成功响应”时重复扣款或重复建单。三道证据门解决的是正确分类，幂等与补偿解决的是分布式副作用，两者不能互相替代。
同时，重试策略要看请求语义：纯查询通常可以有限重试，创建订单、发券、扣款等写操作必须先确认对方是否支持幂等键。没有幂等保障时，不能因为本地只看见超时就认定远端没有执行，更不能用无限重试“提高成功率”。真正可靠的做法是保存请求标识和本地状态，随后通过查询接口或对账任务收敛到权威结果。
7. 我把规则做成了一个真实可交互页面
为了让审查不只停留在代码块，我在现有mci_demo中增加了“HTTP 响应证据门”页面。页面可以切换四种模拟响应，并立即看到三道门的 PASS、BLOCK、SKIP。v0.4.0已完成构建、流式发布与远端回读：应用版本为 v0.4.0，运行清单的 3 个资产完成哈希校验，新路由也已回读到在线页面清单。
截图来自本轮发布后的真实静态入口，但页面里的响应数据有明确的DEMO · SIMULATED RESPONSES标识。它证明交互页和规则模型已交付，不证明某个第三方生产接口当前可用。真实上线仍要在隔离环境覆盖超时、断网、429、非 JSON、重复投递和响应前重启等情况。
8. 成功不是一个字符串，而是一条证据链
这次修改最后只留下一个很简单的原则：**不要从 Content 的外观推断成功。**完整响应先保留事实，传输门确认请求走完，协议门确认 HTTP 接受，业务门确认目标状态成立；随后再按错误类别决定重试、提示、补偿或终止。
AI 可以快速写出调用代码，但“能跑”与“不会误报成功”之间，差的正是这些可观察、可测试、可回读的证据门。下一次看到一段漂亮 JSON，我会先看 StatusCode，再决定它究竟是结果，还是一份结构化的失败说明。
