css引入顺序为：基础样式→业务通用样式→页面或模块样式。基础层含reset、工具类和变量；业务层含布局、主题及基础组件；页面层粒度最细且须最后加载，确保可覆盖性。
CSS引入顺序的核心原则是：基础样式（重置、工具类）→ 业务通用样式（布局、主题、全局组件）→ 具体页面或模块样式（含组件实例化样式）。这个顺序确保低层样式可被高层覆盖，同时避免意外的层叠污染。
基础样式层（reset + 工具类）
这一层提供最底层的视觉一致性与快捷能力，应最先加载：
- 全局 CSS Reset（如 normalize.css 或自定义 reset）——消除浏览器默认差异
- 原子化工具类（如 .mt-4、.text-center、.flex）——不依赖上下文，仅声明单一属性
- 基础变量定义（:root 中的颜色、间距、字体等 CSS 自定义属性）——供后续所有层引用
⚠️ 注意：此处禁止写任何业务语义类名（如 .header-nav、.product-card），也不应包含媒体查询以外的响应式逻辑。
业务通用样式层（layout + theme + base components）
这一层封装项目共性结构与视觉规范，紧随基础层之后：
立即学习“前端免费学习笔记（深入）”；
- 全局布局容器（.container、.main-layout、.sidebar）
- 主题配置（.theme-dark、[data-theme="light"] 下的覆盖规则）
- 基础业务组件样式（.btn、.input、.card）——定义默认态、尺寸、状态（:hover/:disabled），但不绑定具体业务场景
✅ 建议用 BEM 或类似约定命名，保持语义清晰；所有选择器权重控制在单类名或简单组合（如 .btn.btn--primary），避免嵌套过深。
组件与页面样式层（page + widget + scoped component）
这一层面向具体功能，粒度最细，必须放在最后以保证可覆盖性：
- 页面级样式（如 page-home.css、page-profile.css）——只作用于当前路由/视图
- 独立组件样式（如 ProductList.css、CommentForm.css）——含内部结构、状态细节及业务定制
- 若使用 CSS Modules 或 Shadow DOM，该层天然隔离；否则需靠命名空间（如 .page-home__hero、.product-list__item）避免冲突
? 小技巧：对强定制组件，可在其样式中 import 基础工具类（如 @import "./utils.css";），但禁止反向引用——即页面样式不得 import 业务组件样式。
额外建议：构建与维护视角
实际工程中，可通过以下方式固化顺序：
- 入口 CSS 文件按层级 import（如 index.css → @import "base.css"; @import "layout.css"; @import "pages/home.css";）
- Webpack/Vite 中用 postcss-import 插件统一管理，禁用无序 link 标签硬引入
- 在 stylelint 配置中启用 order/properties-order 和 no-duplicate-selectors，配合注释区块标记层级（/* === BASE === */）
不复杂但容易忽略：顺序错位常导致调试时“明明改了却没生效”，根源往往不是代码写错，而是样式被更早引入的高优先级规则静默覆盖了。
