怎么组织 CSS 文件结构才不会后期乱成一锅粥
靠目录层级硬分 base 和 component 不够，关键在引用顺序和作用域控制。很多人把文件夹建好了，结果 button.css 里又写了个 .header，或者 base.css 里偷偷加了媒体查询，最后样式打架、覆盖难查。
-
base只放重置、变量、工具类（如.sr-only、.visually-hidden）、基础排版规则（h1–h6、p、ul默认间距） -
component每个文件只负责一个 UI 单元，文件名和最外层选择器必须一致，比如card.css里只出现.card或.card__header这类 BEM 子类 - 禁止跨目录 import：
component/card.css不能@import "../base/typography.css"，统一由入口 CSS 控制加载顺序 - 所有
base文件必须在component之前引入，否则组件里写的h2 { margin: 0 }会干掉你辛苦写的base间距体系
为什么用 @import 容易出问题
Webpack/Vite 等现代构建工具对 @import 的处理不一致，尤其在 CSS 模块化或作用域隔离场景下，@import 会破坏局部作用域，也可能导致重复注入相同变量。
- 开发时热更新失效：改了
base/variables.css，但component/button.css里@import了它，改动可能不触发重编译 - Tree-shaking 失效：
@import是运行时合并，打包时无法识别哪些变量/规则实际被用到 - 推荐做法：用构建工具的入口 CSS 统一
@import，例如index.css里按顺序写：@import "./base/reset.css"; @import "./base/variables.css"; @import "./base/utils.css"; @import "./component/button.css"; @import "./component/card.css";
如何防止 component 样式污染全局
不是所有项目都上 CSS-in-JS 或 Shadow DOM，纯 CSS 场景下，靠命名约束 + 构建时前缀更现实。
- 强制使用 BEM 命名：
.button、.button--primary、.button__icon，禁用.btn这类缩写，避免和第三方库冲突 - 构建阶段加前缀（如 PostCSS
postcss-prefix-selector）：给整个component/card.css加.myapp-前缀，生成后是.myapp-card，不影响源码可读性 - 如果用了 CSS Modules，确保
component下每个文件都启用，且base类不走 Modules（否则变量无法共享） - 检查 DevTools：打开页面，看元素 computed styles 里有没有意外来自
base的 margin/padding 被component覆盖——这是引用顺序错了的典型信号
base.css 里哪些东西绝对不能写
base 是地基，不是杂物间。一旦塞进不该有的内容，整个样式系统就失去可预测性。
立即学习“前端免费学习笔记（深入）”；
- 禁止写具体业务类名：
.homepage-banner、.user-profile-card—— 这些属于component或页面级 CSS - 禁止写带 JS 行为绑定的类：
.is-open、.has-error必须放在对应组件文件里，否则状态样式散落各处，维护成本飙升 - 禁止写无上下文的尺寸值：
width: 320px、font-size: 14px应该用rem或自定义属性（--size-sm），并统一在variables.css定义 - 媒体查询尽量收口：
base里只放根字体适配（html { font-size: ... }），复杂响应逻辑交给component自己处理
真正难的不是分目录，而是每次写新样式时，能下意识问一句：这个规则，是所有组件都依赖的底层契约，还是某个具体模块的实现细节？答错一次，后面就得花十倍时间 debug。
