应使用引入公共CSS文件并置于页面专属样式之前，禁用@import，通过CSS自定义属性实现轻量配置，构建阶段用CSS Modules或提取插件确保样式唯一打包。
如何用正确引入公共样式表
多个页面共用同一套 CSS，最直接的方式是把通用样式抽成单独文件，用 <link> 在每个 HTML 中引用。关键不是“能不能引”，而是“怎么引才不会冲突或重复加载”。
常见错误是：在某个页面里既通过 <link href="common.css"> 引了公共样式，又在另一个 <style></style> 标签里手写了一模一样的按钮规则——结果样式被覆盖、调试时找不到来源。
- 所有通用样式（重置、字体、基础布局类、工具类）必须只存在于一个
common.css文件中，且不被任何页面内联覆盖 - 每个页面的
中，<link>必须放在所有页面专属样式之前，确保优先级可控 - 避免使用
rel="stylesheet" media="all"以外的media值（如print），除非真有打印专用样式，否则可能被浏览器延迟加载甚至忽略
CSS @import 为什么不该用于跨页面共享
@import 看起来能“导入”另一个 CSS 文件，但实际在页面级复用中基本是负优化。它会阻塞渲染，且无法被现代构建工具有效合并或提取。
比如在 page-a.css 开头写 @import "common.css";，再把 page-a.css 引入 HTML —— 浏览器要先下载 page-a.css，解析到 @import 后再发起第二次请求，加载顺序不可控，还可能触发 FOUC（Flash of Unstyled Content）。
立即学习“前端免费学习笔记（深入）”；
审查 Vue 管理后台的变更请求（Vue 2 + Element UI，Vue 3 + Element Plus）。重点关注最小化变更实现、上线风险检查以及回归检查清单生成。
- 构建阶段（如 Webpack、Vite）可以用
@import，但产出必须是单个打包后的 CSS 文件，不能让@import出现在最终上线的 CSS 中 - 如果没用构建工具，就彻底放弃
@import，全部改用<link>并确保路径一致 - 注意：CSS 中的
@import和 JS 的import完全不同，前者无模块作用域，后者有
如何用 CSS 自定义属性（CSS Variables）做轻量模块化
纯 CSS 没有真正的模块系统，但 :root 声明的自定义属性可以模拟“配置层”，让不同页面按需调整视觉变量而不改结构样式。
比如 common.css 里写：
:root {
--primary-color: #007bff;
--spacing-xs: 4px;
--border-radius: 4px;
}，而 dashboard.html 可以在自己的 <style></style> 中覆盖：:root {
--primary-color: #28a745;
}。这样按钮、标题等复用组件会自动响应新颜色，无需复制粘贴整套规则。
- 变量名统一用
--开头，命名带业务前缀（如--admin-header-bg），避免和第三方库冲突 - 不要把复杂逻辑塞进变量（比如
--shadow: 0 2px 4px rgba(0,0,0,0.1), 0 4px 12px rgba(0,0,0,0.08);可以，但--button-styles这种无效） - IE 不支持自定义属性，如果还要兼容，就得用 PostCSS 插件降级，或者老老实实用
class控制
构建工具中 CSS 模块化的实际落地点
真正解决“相同样式被多次引入”的问题，靠的是构建阶段的依赖分析，而不是运行时技巧。Webpack 的 css-loader 默认开启 modules: false，意味着所有 import './button.css'; 都是全局注入——这正是重复样式的根源。
如果你用的是现代框架（React/Vue），推荐两条路：
- 全局样式走
common.css+<link>，组件级样式用 CSS Modules（开启modules: true）或 CSS-in-JS，天然隔离 - 用
MiniCssExtractPlugin把所有import的 CSS 提取为一个main.css，确保最终只输出一个文件，而非每个组件一个 CSS - 检查打包产物：用
npm run build后搜common.css是否出现在多个 chunk 中；如果有，说明splitChunks配置没生效
模块化不是加个 import 就完事，得看它最后有没有被合并、有没有被复用、有没有被浏览器缓存住。很多“样式重复”问题，其实卡在构建配置漏了一行 cacheGroups。
