layout.css 应仅包含跨页面一致的骨架样式，如body重置、基础变量、栅格容器、页头页脚结构类和响应式断点；严禁业务样式、语义类、!important、元素选择器及伪类交互规则。
layout.css 应该只放哪些样式
它不是“所有公共样式”的垃圾桶，而是页面骨架的最小公约数。只放真正跨页面一致、且不依赖具体业务逻辑的规则。
比如：body 重置、基础字体和颜色变量定义、栅格容器（如 .container）、通用页头页脚结构类（.header-layout、.footer-layout）、响应式断点声明（@media --sm）。
以下内容**必须排除**：
-
.btn-primary—— 按钮样式通常随业务模块变化，应放在组件或页面专属 CSS 中 -
.article-title—— 内容区域样式属于具体页面语义，layout 层无权约定 - 任何带
!important的规则 —— 它会破坏后续样式的可覆盖性 - 直接作用于
div、span等元素的选择器 —— 容易意外污染其他页面
引入 layout.css 的顺序不能错
CSS 是从上到下解析并层叠的，layout.css 必须是第一个被 <link> 引入的样式表，否则它的重置和基础变量可能被后面加载的样式覆盖掉。
立即学习“前端免费学习笔记（深入）”；
正确顺序示例：
<link rel="stylesheet" href="/css/layout.css"> <link rel="stylesheet" href="/css/page-home.css"> <link rel="stylesheet" href="/css/components/card.css">
常见错误：
- 把
layout.css放在page-home.css后面 —— 导致body { margin: 0 }失效 - 用
@import在其他 CSS 文件里引入layout.css—— 加载阻塞、无法并行、且部分浏览器不支持条件 import - 通过 JS 动态插入
<link>—— 可能触发 FOUC（Flash of Unstyled Content）
如何避免 layout.css 被业务样式污染
核心原则：layout 层不写具体业务语义，只提供“壳”和“钩子”。一旦发现某个样式只被一个页面用到，就立刻把它移出去。
实操建议：
- 给 layout 类加命名空间前缀，比如
l-container、l-header，避免和业务类名冲突 - 用 CSS 自定义属性（
--color-bg-base）代替硬编码值，让业务层通过 :root 覆盖，而不是重写选择器 - 禁止在
layout.css里写媒体查询以外的伪类，比如.l-header:hover—— 交互行为属于组件层职责 - 上线前用工具扫描（如
purgecss配合白名单）确认layout.css中每个类都在至少两个页面中被使用
Webpack/Vite 项目里怎么管理 layout.css 的路径和复用
不要靠相对路径硬写 ../css/layout.css，容易因目录层级变动失效。统一走别名或公共入口。
推荐做法：
- Vite：在
vite.config.ts中配置resolve.alias，比如{ '@styles': path.resolve(__dirname, 'src/styles') }，然后所有页面都用@import '@styles/layout.css'; - Webpack：用
resolve.alias+style-loader的insert选项确保 layout 插入在最前 - 如果用 CSS-in-JS（如 Emotion），把 layout 变量抽成 JS 对象导出，CSS 规则仍保留在独立文件中，避免运行时注入顺序失控
- 注意：Vite 的
css.preprocessorOptions不会作用于纯.css文件，所以layout.css里不能写var(--color)却不配 postcss-preset-env
layout.css 里塞——它越“瘦”，后续页面就越不容易被拖垮。 
