模型返回的 JSON 太大或嵌套太深，怎样在解析前设资源边界

模型允许输出多少 token，与客户端愿意解析多少字节不是一个限制。中文、表情和转义都会改变字节数量；嵌套很深的短文本也可能给解析器带来资源压力。因此客户端应有自己的接收与解析预算，而不是只依赖请求里的输出上限。

字节预算先于完整对象构造

本文演示预算为 UTF-8 编码后一百二十八字节、最大结构深度四层，都是便于复核的小值，不是厂商限制或生产推荐。缓冲阶段累计实际接收字节，超过预算就隔离；不能保留前一百二十八字节，再把截断文本交给业务解析器当完整结果。

完整文本进入深度扫描前仍要经过正确的编码处理。本篇只讨论 JSON 的字节与结构预算，不实现网络跨块解码，也不把一次长度检查称为完整资源沙箱。对于真实大响应，应在缓冲期间就执行上限，避免先全部装进内存再拒收。

括号必须在正确状态下计数

扫描器维护是否在字符串内、前一字符是否为转义的状态。只在字符串外对花括号和方括号增减深度；字符串里的 "[[[[[[" 不应触发超深。反斜杠转义引号也不能让扫描器过早退出字符串，否则后面的普通括号会被误当结构。

附件正常小对象通过，长中文字符串触发字节预算，五层数组触发深度预算，含许多字面括号的字符串仍通过。检查器另外把语法错误送给 JSON 解码，确保预检不负责把错误文本修成合法对象。预算通过后仍须检查语法、字段类型与业务约束。

拒绝与修复是不同动作

反例是删除多余的闭括号或自动补齐尾部，直到 json.loads 不报错。它会改变模型原始数据，且可能掩盖响应未完成。正确做法是保存预算类型、观察到的大小或深度和安全摘要，再由调用方决定重试、分段或缩小任务。本文不会发起任何重试请求。

扫描本身也消耗线性时间，所以字节上限是更早的一道门。遇到负深度、未闭字符串等情况，不要据此继续解析大型内容；小输入可交由标准语法检查给出错误，超预算输入则直接拒绝。错误类别保留独立，便于判断需要调容量还是修结构。

若业务确实需要更深的合法对象，应明确修改预算并重放旧样本，而不是捕获递归错误后无限提高解释器限制。本文验证的是合成文档在本地合同下的资源预检，不涉及 HTTP 服务端准入、网关请求体限制或租户配额，也不承诺任何模型平台的返回大小。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a017.json，离线检查器 a017.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a017.py。

一手资料1。资料核对日期：2026-10-24。