Ccscsearching发布于 7 小时前
0560
目录 · 5 个章节
接 API 中转时，“能调通”和“能上生产”差得挺远。下面是 Folkbench 博客里一套可重复的验收流程，我按自己的理解整理了一下，分享给有类似需求的同学。
1. 先把请求固定下来
- 准备一份不含真实用户数据的固定请求样本
- 记录：模型 ID、请求体、是否流式、超时、重试预算、测试时间
- 测试凭证放本地 secret manager 或临时环境变量，不要进日志、截图、仓库
2. 非流式、流式分开测
- 非流式：对照文档检查 HTTP 状态、响应头、响应体，记录 request ID 和总耗时
- 流式：记录首个有效 chunk 的时间、chunk 是否持续到达、有没有完成事件、断开时客户端能不能拿到明确结果
- SSE 是事件流，按事件边界解析，别按网络包边界去猜
3. 失败要分类
| 类型 | 期望表现 |
|---|---|
| 客户端错误（模型名错、缺参数） | 返回可诊断的 4xx |
| 鉴权错误 | 明确拒绝，不泄露其他凭证或内部地址 |
| 上游错误（超时、限流、临时故障） | 能区分可重试 / 不可重试 |
| 流式中断（缺完成事件、半截 JSON） | 进失败分支，不能当成正常文本 |
4. 重试要有边界
- 只重试幂等或可安全重放的请求
- 设总重试预算，关联首次和最后一次 request ID
- 鉴权失败、参数错误、内容策略拒绝不要盲目重试
5. 先写通过标准，再测
比如：“固定请求三次独立尝试都返回完整结果，流式有明确完成事件，鉴权失败从不重试。”看到结果后不改标准。测完撤销临时凭证、删掉本地原始响应，只留摘要、时间戳和版本。
完整版（含验收表模板）在这里，不用注册就能看： https://folkbench.com/blog/api-relay-reliability-checks?utm_source=luntan&utm_campaign=cnode
说明：这是一份操作模板，不是对任何中转的实测结论。
想问问大家：你们接中转时踩过最坑的是哪类问题？流式断流被当成正常输出这种，你们是怎么兜底的？