常见问题
先用简短答案确定问题属于哪一层，再进入对应文档处理，不必从头翻完整个接口目录。
遇到请求失败时，先保留 HTTP 状态码、响应体、请求时间和请求 ID。缺少这些信息，只靠“不能用”通常无法准确定位。
接入与凭证
我还有余额，为什么请求仍然失败？
余额只是账户层信息。还需要检查：
- API Key 是否完整、启用且未过期
- 当前 Key 是否触达独立额度
- 模型是否对当前账号可用
- 是否触发请求速率、并发或任务限制
从 额度与计费 区分账户和 Key 边界，再根据状态码进入 错误处理。
页面里的“令牌”和文档里的“API Key”是同一种东西吗？
在当前产品语境中，它们都指调用接口时使用的访问凭证。请求头使用：
Authorization: Bearer <完整 API Key>不要只复制页面中用于识别的前缀，也不要把完整密钥写入前端或公开仓库。
为什么既需要 Base URL，又需要模型名？
它们解决两个不同问题：
创建 Key 后应该从哪里开始？
按 5 分钟完成第一次请求 发出一条最小文本请求。先证明地址、Key 和模型可用，再接入 SDK 或第三方客户端。
客户端与请求
为什么 curl 能用，第三方客户端却失败？
优先比较以下差异：
用相同地址、Key、模型和最小消息做对照，逐项排除，不要同时修改所有设置。
同一把 Key 为什么在两个工具中表现不同？
Key 只解决鉴权，不会统一不同工具的模型预设、接口路径、超时、流式实现和重试策略。比较两个工具实际发出的请求，通常比反复创建新 Key 更有效。
为什么同步请求没有立即返回？
可能是输入较大、生成时间较长、客户端超时过短，也可能该能力实际返回了异步任务。先确认是否收到任务 ID，再到 任务中心 或 模型与任务 查询。
模型与平台
文档示例中的模型为什么不能直接调用？
示例名称用于说明请求结构，不代表每个账号都开放同一模型。应通过 GET /v1/models 或控制台确认可用模型，再用真实请求验证。
为什么文档讲模型，控制台里还会出现渠道？
调用侧主要按模型选择能力；平台侧还需要组织模型资源和调用路径，因此会出现渠道概念。普通调用方应先关注模型名称是否准确、请求是否成功，渠道更多用于平台配置与问题定位。
首页和文档都能打开，为什么 API 仍然报错？
文档页面、API 网关、模型执行、异步任务和账单记录属于不同链路。页面可访问只能说明文档站点正常，不能证明 Key、模型、额度和模型服务都可用。
用量与重试
请求失败会不会产生费用？
不能只根据客户端最后显示的“失败”判断。请求可能在客户端超时前已经进入执行，任务也可能已经创建。应结合状态码、任务记录和用量变化确认，详见 计费规则。
为什么只点了一次却出现多条请求？
常见原因包括页面重复提交、SDK 自动重试、网络层重放或异步任务被重复创建。记录每次请求的唯一 ID，并检查客户端最大重试次数。