应按基础层、组件层、布局层、主题层四层组织CSS结构，分别对应base.css、components.css、layout.css、theme.css，配合@layer分层或命名空间前缀控制作用域，变量需语义化并全程中转，class命名重业务语义轻语法规范。
初始 CSS 文件结构怎么组织才不踩坑
项目刚起步时，别急着写一堆零散的 .btn、.card 类，先搭骨架。核心是分离「基础层」「组件层」「布局层」「主题/覆盖层」四类规则，否则三个月后改一个按钮圆角会牵出十五个文件。
-
base.css：重置（box-sizing: border-box必加）、字体栈、默认链接/列表样式、CSS 自定义属性（如--color-primary）声明 -
components.css：只放可复用、无上下文依赖的模块，比如.button、.input-field，禁止出现.sidebar .button这类嵌套 -
layout.css：仅含容器类，如.container、.grid、.flex-col，不涉及颜色、边框等视觉细节 -
theme.css（后期加）：只覆盖变量值，比如:root { --color-primary: #5e35b1; }，不写选择器
class 命名要不要上 BEM？什么时候该停手
BEM 有用，但不是所有项目都值得。中大型团队、多人协作、需长期维护的项目建议用；小工具、内部后台、一次性活动页，用语义化短名（search-input、user-avatar）更轻量。关键不是命名法本身，而是「能否一眼判断作用域和层级」。
- 避免
.header__title--large这种过度修饰：尺寸应由设计系统约束，不是靠 class 叠加 - 警惕
.btn-primary--disabled：状态应通过[disabled]属性或.is-disabled布尔类控制，而非修饰符 - 如果发现 60% 的 class 都带双下划线（
__）或双破折号（--），说明抽象过早，先退一步写清楚业务语义
如何让新增页面样式不污染全局、又不重复造轮子
新页面加样式，第一反应不该是“我来写个 .page-home”，而是查三件事：有没有现成布局类能组合？有没有基础组件可配置？有没有变量可覆盖？只有这三条都走不通，才新建局部作用域。
- 用
@layer显式分层（Chrome 110+ / Safari 17.4+ 支持）：@layer base { /* reset, vars */ } @layer components { /* buttons, cards */ } @layer pages { /* .page-home only here */ }后续扩展时，@layer pages内样式天然不会影响前面两层 - 若需兼容老浏览器，改用命名空间前缀：
.page-home .button→.page-home-button，但必须配合构建工具自动加前缀（如 PostCSS plugin） - 禁止在页面样式里重写
body、h1等全局标签样式——那属于base.css职责，改就去那里改
后期加暗色模式 / 多主题时最常崩的是哪几处
崩点往往不在主题切换逻辑，而在初始变量设计。如果 --bg-color 直接赋值 #ffffff，而不是指向一个语义变量如 --surface-bg，换主题时就得满项目搜 #ffffff 替换，必漏。
立即学习“前端免费学习笔记（深入）”；
- 所有颜色、间距、阴影值必须走变量中转：
:root { --surface-bg: #ffffff; --text-primary: #333333; } .dark-theme { --surface-bg: #121212; --text-primary: #eeeeee; } - 慎用
prefers-color-scheme直接写样式：它无法响应用户手动切换，应仅作 fallback，主逻辑靠 class 切换（html.light-theme/html.dark-theme） - 图片、SVG 图标中的颜色如果写死内联色值（
fill="#333"），主题切换时不会变——统一用fill="var(--text-primary)"
真正卡住扩展性的，从来不是技术选型，而是变量命名是否反映意图、class 是否有明确边界、以及每次加新样式时有没有问一句：“这个规则，三年后还敢动吗？”
