样式表引入顺序决定层叠效果，后加载规则覆盖先加载的同名属性；@import应避免使用，内联和style标签优先级更高但仍遵循声明顺序；高特异性与!important破坏可维护性；现代架构依赖低特异性和命名约定；动态插入需用JS控制时机并监听onload；构建工具可能改变原始顺序，应以开发者工具为准。

样式表引入顺序直接影响最终渲染效果

浏览器按 HTML 中 和 @import 出现的**从上到下、从左到右**顺序解析 CSS，后加载的规则会覆盖先加载的同名属性。这不是“谁更强”，而是纯粹的层叠（cascade）顺序问题。

• @import 必须写在 CSS 文件开头，且会阻塞后续样式解析，实际项目中应避免在 CSS 里用 @import 引入其他 CSS
• HTML 中多个 标签，位置靠后的文件中定义的 .btn { color: red; } 会覆盖靠前文件里的 .btn { color: blue; }
• 内联样式（style="..."）和 标签内容也参与层叠，优先级高于外部文件，但它们的声明顺序依然生效：后写的规则覆盖先写的

用 specificity 而非加载顺序强行“抢权重”是危险操作

很多人遇到覆盖失败就堆 !important 或写 div.container ul li a:hover 这类超长选择器。这看似“赢了”，实则埋下维护雷：

• !important 会破坏可预测的层叠逻辑，后续想覆盖它必须再加 !important，形成恶性循环
• 高 specificity 选择器（如 #header .nav > li.active a）会让组件难以复用，一挪位置就失效
• 现代 CSS 架构（如 BEM、CSS Modules）依赖低 specificity 和明确的作用域，靠加载顺序+命名约定来规避冲突，而不是拼权重

真正可控的加载控制：动态插入 + onload 回调

当必须保证某份样式最后生效（比如主题色切换、运行时注入 UI 框架样式），不能只靠 HTML 静态顺序，得用 JS 控制插入时机：

const link = document.createElement('link');
link.rel = 'stylesheet';
link.href = '/themes/dark.css';
// 插入到  最末尾，确保层叠位置靠后
document.head.appendChild(link);

// 等待加载完成再触发依赖该样式的逻辑
link.onload = () => {
  document.body.classList.add('theme-dark');
};

• 不要用 document.write() 插入样式——已废弃且会清空页面
• 避免在 DOMContentLoaded 之后才插入关键样式，可能造成 FOUC（Flash of Unstyled Content）
• 若需替换样式（如换肤），推荐先移除旧 ，再插入新 link，而不是靠 disabled 属性——部分浏览器对 disabled link 的层叠处理不一致

构建工具链中的隐式顺序陷阱

Webpack/Vite 等工具常把 CSS 提取为单个文件（如 main.css），此时原始引入顺序被扁平化，容易误判“为什么我后写的样式没生效”：

• Vite 默认开启 css.preprocessOptions，若用了 @import，Sass/Less 的导入顺序 ≠ HTML 中 link 顺序
• Webpack 的 MiniCssExtractPlugin 会合并所有 CSS 模块，最终输出顺序取决于模块依赖图，而非源码书写顺序
• 解决方案：用 /*#__PURE__*/ 注释或拆分 entry，或改用 CSS-in-JS 库（如 Linaria）让样式作用域完全隔离