Safe 与 Mock
两种密钥模式的差异，以及 mock 如何决定返回内容。
每个密钥在创建时就确定是 safe 密钥还是 mock 密钥。
对照
| Safe | Mock | |
|---|---|---|
| 上游请求 | 转发到供应商 | 从不发出 |
| 使用的凭据 | 加密托管的上游密钥，仅在网关内解密 | 无 |
| PV / UV 配额 | 消耗 | 不消耗 |
| 告警与拦截 | 生效 | 不适用 |
| 响应 | 供应商原样返回 | 网关生成的、与供应商格式一致的响应 |
| 适用场景 | 生产环境 | 开发与演示 |
模式在密钥上，不在 URL 上
base URL 只决定访问哪个平台。这次请求是转发还是本地应答，由请求携带的凭据 决定，因此 mock 密钥与 safe 密钥的用法完全相同。
网关只对 safe 密钥做转发，所以 mock 密钥不可能打到真实供应商。
密钥只能在自己平台的前缀上使用
前缀决定平台，密钥必须与之一致。把 OpenAI 的密钥用到 /deepseek/… 会被拒绝，
而不是转发到不该去的地方。具体响应体见 错误。
Mock 如何决定返回内容
Mock 不转发，因此必须从请求本身推断响应：
| 平台 | 判定方式 |
|---|---|
| OpenAI、DeepSeek | 读路径（/chat/completions → 文本，/images/generations → 图片），其余情况回落到密钥的媒体类型 |
| Claude | 一律按 /v1/messages 响应 |
| fal.ai | 取自密钥的媒体类型；前缀决定同步或队列 |
| ByteDance Seedance | 方舟任务流程，按路径判定 |
Playground 可以在任一模式下发送请求并查看原始响应。