样式表引入顺序决定层叠效果，后加载规则覆盖先加载的同名属性；@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）让样式作用域完全隔离
Computed 面板，看某条样式究竟来自哪个 source 文件的哪一行，比猜“我是不是引错了顺序”快得多。 
