Lesson 09 · 排障

故障分诊：拿到报障，先判归属层

前八课每课都往分诊表里塞了几条。这一课把它们串成一套可以照着走的流程。

课 01–04 已经出正文，够你把项目跑起来、看懂一次请求、看懂页面和状态。 05–09 属于「能独立干活」阶段，需要几个真实的历史报障案例 —— 编出来的案例练不出分诊能力才能写得可靠。

下面的目录不是占位符 —— 每一条都已经在源码里核对过入口， 你现在就可以照着自己去读。

为什么排在这个位置

这是整个课程的终点，也是这个岗位的核心能力：别人给你一句模糊的描述，你能在十五分钟内给出带证据的根因。

排在最后，因为分诊靠的是前面所有课积累的「这个症状可能来自哪几层」的映射。没有那些积累，分诊表只是一张纸。

分诊的第一问永远是「哪一层」。渲染 / 主进程 / 子进程 / 网络 / 外部服务 / 凭据 / 平台 —— 七个候选，先排除到两个以内
七层各自的第一检查点。每层给一条最快的判定动作，比如凭据层就是 JSON.parse(localStorage.getItem("GameENV"))
把模糊描述翻译成可检查的命题。「保存没反应」→「请求发出去了吗 / 打到哪台服 / 参数对吗 / 服务端返回了什么」
本项目特有的五个高频误判。按 URL 筛 Network（没用，要看 cmd）、以为菜单隐藏就是无权限、把「没选服」当成代码 bug、把 Mac 上的 exe 失败当成环境损坏、在 serviceold.ts 里改代码
静默失败的识别。本项目大量操作失败时不报错，「没有错误信息」本身是一条强信号
演练：三个真实案例。从一句话描述走到带 file:line 的根因
怎么写一份能交出去的排查结论。症状 / 复现步骤 / 归属层 / 证据 / 根因 / 处置 / 是否需要他人配合