GLM-5.3-FlashX 返回空内容还报错——是参数没对齐还是额度用尽？

空内容和报错同时出现，通常说明问题不在“模型答不好”，而在请求还没被正常受理。这三类原因在日志里的表现并不一样：参数没对齐一般拿到 4xx，响应体里往往点名了字段；密钥或权限问题集中在 401、403；额度与限流则多是 429，或者状态码 200 但响应头里带限流信息。所以建议先别改业务代码，把完整状态码、响应头和响应体落盘，再按状态码分流。

先看完整响应码再改代码：4xx 优先查参数与认证，429 优先查限流与额度，200 但内容为空则要查流式解析和 content 的取值路径。适用场景是所有“报错 + 空内容”的调用；操作动作是在 HTTP 层记录状态码、响应头、响应体各一次；验证方式是用同一份 payload 手工复测；边界是具体错误码含义与限流头字段名要以接口实际返回为准，SDK 封装和直连 HTTP 暴露的信息量并不相同。

打印完整响应状态码和响应体定位错误类型

SDK 抛出的异常字符串常把状态码吞掉，只留一句“请求失败”，这会把参数问题和认证问题混在一起。建议在发请求的那一层加日志，成功失败都打，便于比对：

resp = session.post(url, headers=headers, json=payload, timeout=60)
logger.info("status=%s request_id=%s", resp.status_code, resp.headers.get("x-request-id"))
logger.info("headers=%s", dict(resp.headers))
logger.info("body=%s", resp.text[:2000])

拿到状态码后先按通用含义分类，再去看响应体里的具体描述：

400：请求体语法或字段不合法，模型端一般会指出是哪个字段；JSON 里用了中文引号、尾随逗号也常落在这里
401：认证没通过，密钥缺失、格式不对或已失效
403：身份被识别出来了但没有权限，常见于密钥不绑定该模型
404：路径写错或模型标识不存在
413 / 422：请求体过大，或字段类型不符合要求
429：触发限流或额度耗尽
500 / 502 / 503 / 504：服务端或前置网关的问题，先看是否持续出现，不要立刻改参数

还有一种容易被误判成报错的情况：状态码是 200，但 choices 数组为空，或 message.content 是空串。这类不是错误码问题，多半与流式解析、max_tokens 给得太小或被内容策略截断有关，属于下一节要核对的参数范畴。

逐项核对请求参数名称与格式

参数错位的典型症状是请求能发出去、服务端也回 4xx，但错误信息很简短。建议把业务里组装的 payload 原样打印，再用同一份 payload 手工发一次；能复现，就说明是参数问题，而不是网络或额度。

{
  "model": "在此填入账号实际可用的模型标识",
  "messages": [
    {"role": "user", "content": "只回复 ok"}
  ],
  "stream": false
}

对照官方文档逐项过一遍，重点看这几处：

model：值要和账号可用的模型标识一致，注意大小写、连字符和版本别名，别名与具体版本号有时不通用
messages：必须是数组，每项包含 role 和 content；role 用文档规定的取值，不要自造
content：纯文本场景一般是字符串，多模态场景才用数组；两种格式混用容易触发类型错误
stream：为 true 时返回的是 SSE 流，要逐行读 data: 前缀再拼接，不能直接当普通 JSON 解析；排查阶段建议先设为 false
max_tokens、temperature、top_p：传数字类型，别传成字符串
未知字段：文档里没声明的字段不要顺手加上，有的网关会做严格校验

验证方式是用最小 payload 先跑通，再把业务参数一项一项加回去，加到哪一项开始失败，问题就在那一项。

验证 API 密钥与权限范围

确认密钥是否有效，最省事的做法是绕开业务封装，用一条最小请求单独打一次：

export API_KEY="你的密钥"
export BASE_URL="接入点基础地址"
curl -s -o resp.json -w "%{http_code}\n" \
  -X POST "$BASE_URL/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"在此填入模型标识","messages":[{"role":"user","content":"hi"}],"stream":false}'
head -c 800 resp.json

结果怎么读：401，或响应体里出现 invalid、unauthorized、api key 之类的字样，基本是密钥本身的问题；403 说明密钥被认出来了但没有该模型或该接口的权限，需要确认密钥绑定的模型范围、子账号权限，以及对应服务是否已开通。

几个可验证的复查点：密钥是否带了首尾空格或换行；Authorization 头里 Bearer 前缀是否重复；环境变量是否真的在运行进程或容器里生效，而不只是写在了本地 shell；密钥是否已被轮换或删除。这些都能从日志和一次手工请求里看出来，不需要猜。

查看额度与限流信息的途径

额度用尽和瞬时限流都可能给 429，但恢复方式不同：额度用尽会持续失败，直到充值、更换密钥或进入下一个计费周期；瞬时限流稍等一会儿或降低并发就能过去。区分二者，看响应头或控制台的用量信息。

不少平台会在响应头里回带限流信息，字段名并不统一，常见形如 x-ratelimit-limit、x-ratelimit-remaining、x-ratelimit-reset、retry-after。是否真的存在要以你的接口返回为准，可以先通配打印一遍确认：

for k, v in resp.headers.items():
    if any(t in k.lower() for t in ("rate", "quota", "retry", "limit")):
        logger.warning("limit header %s=%s", k, v)

控制台一侧，通常在账号的用量或计费页面能看到余额、按模型拆分的消耗明细和限流说明。如果 429 出现后很短时间就能恢复，更偏向限流；如果一直失败、用量页面上的剩余额度已经见底，更偏向额度用尽。

重试要克制：带指数退避和次数上限，别在高并发下密集重试，否则会把限流窗口拖得更长。如果响应头里没有任何限流字段、控制台也看不到明细，可以固定间隔重试两三次，用行为反推它属于哪一类，再决定是调整调用节奏还是先处理额度。