样式丢失先核对类名,再怀疑缓存与权限

**「CSS 完全没渲染」这类现象,排查顺序应从「当前组件用的类名」与「CSS 文件里实际存在的类名」是否对得上开始,而不是先怀疑缓存或文件权限。** 类名对不上是最高频、也最容易被跳过的根因:文件存在、import 正常、规则上千行,看起来一切都对,但组件根本不用这些选择器。

排查顺序

顺序检查说明
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 —— 同类:先分清「本来就没有」与「这次没加载出来」