样式丢失先核对类名,再怀疑缓存与权限
排查顺序
| 顺序 | 检查 | 说明 |
|---|---|---|
| 1 | 类名是否匹配 | 重写组件(如 page.tsx)后,CSS 若停留在旧版类名上(旧版 grid 卡片类 vs 新版索引页类),规则再多也全部不命中 |
| 2 | 编辑历史是否弄丢了样式 | 用脚本改写 CSS 时容易把规则插到顶部或覆盖掉主体,导致「文件在、样式没了」 |
| 3 | 文件权限 | -rw-------(600)这类权限确实可能让构建进程读不到,但它是次要嫌疑,放在类名之后 |
反面教材:先按权限和 import 排查,得出「一切看起来正常」的结论;真正原因是改造索引页时把新样式写进了另一个文件(后又删除),而 wiki.css 从未同步到新版类名。
延伸:截图 ≠ 代码(HMR 中间态)
缓存/热更新不只是「看不到最新」,也可能让你看到不存在的中间态:dev server 的 HMR 缓存会让页面停留在上一版,于是「代码已回退」而截图仍是旧样子,双方据此互相误判(09-07 13:36 的复盘:用户以为 agent 又改错了,直接要求「回到最初状态」)。
因此判断样式是否生效,以代码为准,不以截图为唯一依据;看到的结果与刚写的代码不符时,先怀疑是中间态(刷新/重启 dev server 再确认),别急着改第三版。
相关
- 入库前先分层清洗 —— 同一习惯:先确认「是不是同一件事」,再往下查
- 高负载发烫先排除负载而非硬件 —— 同类经验:先排除最容易错的那一层
- 讲bug先讲现象再讲根因 —— 沟通层:先对齐「看到的坏」是什么
- 评审设计可行性先问方案再定难度 —— 同轮教训的另一半:改前先复述理解
- 图片加载失败要可重试并升级到HTTPS —— 同类:先分清「本来就没有」与「这次没加载出来」