200，却白得干净

客户截图过来，页面纯白，什么都没有。我一测，状态码 200，五段耗时也正常。

那一刻我意识到，测速只能证明「请求成功了」，证明不了「页面渲染出来了」，两者之间还隔着一整层前端。

三种白屏，三条路线

路线选错，后面全是在绕圈，还容易把无辜的环节改坏。

响应体是空：服务器返回了 200 加一段空内容，得改后端，前端怎么调都没用。

脚本没跑起来：HTML 完整，JS 报错或加载失败，得改资源，查构建和分发。

被跳走了：一路 302 到空白页，得改跳转和路由配置，光看首页代码找不到原因。

用结果先分一下

结果里的字段，刚好对得上这三种，所以第一步永远是先看结果。

下载段接近零：响应体是空的，后端问题几乎可以确定，先去翻应用日志。

下载段有内容、TTFB 正常：说明页面拿到了，问题在前端执行，去看控制台报错。

状态码是 3xx：先跟着跳转走一遍，看最终落到哪个地址，很多白屏是被跳走的。

用宝塔拨测的网站测速跑一次，状态码、五段耗时、内容长度一起看，三种情况基本能分开，不用凭感觉。

为什么不能一起改

改得快不等于改得对，尤其在三样症状混在一起的时候。

三样一起改，白屏消失了也不知道是谁的功劳，下次复发还得从头来。

更麻烦的是，改错了还会引入新问题，比如为了「修白屏」把缓存策略关掉，白屏好了，速度掉一半。

一次只动一层，改完立刻复测，是最省时间的做法，也最容易解释清楚。

分组看是全局还是局部

范围一变，负责的人就变，也才知道该给谁发消息。

所有节点都白屏，问题在服务端或构建产物，跟线路没关系。

只有某些地区白屏，先看 CDN 节点和资源分发是否同步，新版本没推全时最常见。

按运营商分组也有用，某一家白屏通常说明那一路资源加载失败，换个节点就能验证。

复测与收尾

修好和看起来修好，是两件事，复测就是为了区分它俩。

同一地址连测三次，确认白屏不再出现，别只看一次就说修好了。

再换设备实际打开一次，看首屏是否有内容，测速正常不等于用户能看到东西。

把改动和验证结果写在一起，下次同类问题直接查记录，不用重新推理一遍。

白屏这事，先定类型，再谈优化，顺序别反。

反了，就容易越修越乱。

乱了，就该停下来先看结果。

看结果这一步，几乎从不白做。

不白做，时间就没浪费。