先分清平台错误还是应用错误
一、判断依据
| 形态 | 归属 | 往哪查 |
|---|---|---|
500 status code (no body) | 平台(函数超时 / 崩溃) | 平台函数日志、maxDuration、执行耗时 |
{"error": "..."} JSON | 应用代码 | 自己代码里的错误分支 |
格式本身是信号:应用层只要还能返回,就一定会带上自己的错误体;返回不了,才是平台在替你回。
客户端(IDE)的报错同样按「归属层」先分流
Invalid signature, please retry. 这类带 Retry 按钮的英文报错,先别去查自己的代码:先在仓库里搜这个字符串——搜不到、且项目错误文案都是中文、dev server 日志干净,就说明它来自 IDE 的 AI 对话客户端到模型网关的签名校验,与项目代码、worktree、dev server 都无关。
常见诱因:网络代理干扰(请求被篡改/重放)、本机时钟漂移(签名带时间戳)、登录态过期。处理是点 Retry / 加直连规则 / 重新登录,不要当成项目 bug 去改代码。
判据:报错文案的语言与风格和项目不一致 + 仓库里搜不到该字符串 ⇒ 归属在外部层。它只会打断当前那次生成,不会破坏已执行的远程操作(SSH 上跑完的命令是原子完成的)。
二、配套动作
- 先复测线上:如果生产环境此刻 200(哪怕要 14s),说明是间歇性故障,不要按"服务挂了"去改代码。
- 平台函数超时往往和重试链的总耗时耦合(见 轮换要带健康状态记忆:盲目串行 12 组 × 8s = 96s > 60s 上限)。
三、附带的一次误判澄清
「主题闪烁」只在客户端导航时出现(Provider 新挂载,异步读 localStorage,此时页面已有旧主题状态);全页刷新本来就正常,所以"我刷新没遇到"与"存在这个问题"并不矛盾。影响极小 → 优先级低。
相关
- 零延迟零尝试说明请求没发出去(同为「从错误形态反推归属层」)
- GitHub打不开先分清主站与静态资源域名
- 轮换要带健康状态记忆
- 讲bug先讲现象再讲根因
- 先定位归属层再动手 —— 本条是该骨架的一处实例