先分清平台错误还是应用错误
一、判断依据
| 形态 | 归属 | 往哪查 |
|---|---|---|
500 status code (no body) | 平台(函数超时 / 崩溃) | 平台函数日志、maxDuration、执行耗时 |
{"error": "..."} JSON | 应用代码 | 自己代码里的错误分支 |
格式本身是信号:应用层只要还能返回,就一定会带上自己的错误体;返回不了,才是平台在替你回。
二、配套动作
- 先复测线上:如果生产环境此刻 200(哪怕要 14s),说明是间歇性故障,不要按"服务挂了"去改代码。
- 平台函数超时往往和重试链的总耗时耦合(见 轮换要带健康状态记忆:盲目串行 12 组 × 8s = 96s > 60s 上限)。
三、附带的一次误判澄清
「主题闪烁」只在客户端导航时出现(Provider 新挂载,异步读 localStorage,此时页面已有旧主题状态);全页刷新本来就正常,所以"我刷新没遇到"与"存在这个问题"并不矛盾。影响极小 → 优先级低。
相关
- 零延迟零尝试说明请求没发出去(同为「从错误形态反推归属层」)
- GitHub打不开先分清主站与静态资源域名
- 轮换要带健康状态记忆
- 讲bug先讲现象再讲根因
- 先定位归属层再动手 —— 本条是该骨架的一处实例