必须用 kebab-case(中划线分隔),如 header-nav.css;snake_case 在旧版 Windows+Node 中易触发缓存异常,PascalCase/camelCase 易与 JS 模块混淆且不符 HTML 语义惯例。
必须用 kebab-case(中划线分隔),比如 header-nav.css、modal-dialog.css。浏览器和构建工具(如 Webpack、Vite)对文件路径大小写和符号敏感,snake_case(下划线)在部分旧版 Windows + Node 组合中可能触发缓存异常;而 PascalCase 或 camelCase 容易与 JS 模块名混淆,且不符合 HTML link 标签的语义惯例。
常见错误现象:HeaderNav.css 被引入后样式不生效,检查发现实际请求的是 headernav.css(小写化重定向失败)或 404;button_style.css 在某些 CI 环境中被忽略,因 glob 模式默认不匹配下划线。
12col-grid.css → 改为 grid-12col.css
我的按钮样式.css 必须改为 my-button.css
base-reset.css、theme-dark.css
link 引入顺序为什么不能乱?顺序直接决定 CSS 优先级叠加结果,不是“谁在后面谁覆盖”,而是受层叠上下文、选择

base.css 放最后,会导致所有组件样式被重置规则意外覆盖。
正确顺序应为:
使用场景举例:暗色模式切换时,theme-dark.css 必须在 theme-light.css 之后引入,否则无法通过仅切换 disabled 属性来控制生效;组件库(如自建 ui-kit.css)必须放在业务样式之前,否则业务里写 .btn { color: red; } 会被 UI 库更具体的选择器(如 .ui-btn.ui-btn--primary)压制。
立即学习“前端免费学习笔记(深入)”;
@import 替代 link:它会阻塞渲染,且无法并行加载link 或混用 @import)document.createElement('link'))需注意插入位置,建议插在已有 link 末尾不是按页面切分(home.css、about.css),而是按功能维度组织,配合构建工具做按需合并。否则很快会出现样式冲突、重复定义、删除页面时漏删 CSS 的问题。
推荐结构:
styles/
├── base/
│ ├── reset.css
│ └── typography.css
├── layout/
│ ├── grid.css
│ └── container.css
├── components/
│ ├── button.css
│ ├── modal.css
│ └── form.css
└── themes/
├── light.css
└── dark.css
性能影响:单个大文件(如全量 app.css)不利于 HTTP 缓存复用;但拆成 50+ 个独立 link 又增加 HTTP 请求,现代方案是用构建工具输出一个主文件 + 动态加载关键组件 CSS(如用 import('./components/modal.css') 配合 CSS 提取插件)。
components/ 下再建子目录(如 components/button/primary.css),增加查找成本base/ 层禁止出现业务类名(如 .user-avatar)!important,靠选择器层级和引入顺序解决覆盖问题类名本身不强制绑定文件名,但需约定映射关系,否则团队协作时无法快速定位样式来源。例如 card.css 文件里,根类名必须是 .card,子元素用 .card__header、.card--hover,而非 .ui-card 或 .post-card。
容易踩的坑:sidebar.css 里写 .sidenav 类,导致搜索 .sidebar 找不到定义;或多人协作时,A 写了 input.css,B 又建了 form-input.css,两者都定义 .input,最终样式打架。
button.css → .button、.button__icon、.button--large
postcss-bem)或 Sass @use 规则时,确保模块命名与文件名一致"files.associations": {"*.css": "postcss"},避免语法高亮错乱影响识别