样式表引入顺序决定基础优先级：浏览器按HTML中从上到下顺序解析CSS，后加载的同权重规则覆盖先加载的；reset.css须置于业务样式前；@import应全放文件开头；!important仅作用于单声明且不提升选择器权重；权重按(a,b,c,d)四元组计算，非长度决定。
样式表引入顺序决定基础优先级
外部样式表、<style> 标签和 style 属性的加载顺序直接影响最终生效的样式。浏览器按 HTML 中出现的**从上到下顺序**解析并应用 CSS，后加载的规则会覆盖先加载的同名规则（前提是选择器权重相同）。
常见错误：把重置样式 reset.css 放在业务样式之后，结果自定义 button 的 padding 被重置规则覆盖。
- 确保
reset.css或normalize.css在所有业务 CSS 之前引入 - 避免在
<head>末尾插入内联<style>块来“强行覆盖”，应统一管理加载顺序 - 动态插入的
<link>（如 JS 创建）按插入时刻参与层叠，不是按文件路径或声明位置
!important 不是万能解药，但能打破常规层叠
!important 会让该声明在层叠计算中获得更高优先级，但它只作用于单个声明，且会破坏可维护性。它不能提升选择器权重，也不能跨样式表“穿透”作用域。
典型误用：在组件库 CSS 中大量使用 !important 来对抗宿主页面样式，导致升级困难、调试混乱。
立即学习“前端免费学习笔记（深入）”；
-
!important的优先级高于内联style属性（但低于浏览器强制样式，如某些表单控件的 UA 样式） - 多个
!important同时存在时，仍按选择器权重 + 源顺序决定谁胜出 - React/Vue 组件中，CSS-in-JS 方案（如
styled-components）默认为每个规则添加唯一属性选择器，天然规避部分冲突，此时滥用!important更易引发不可预测覆盖
选择器权重计算必须手算，不能靠感觉
权重不是“越长越强”，而是按四元组 (a,b,c,d) 计算：
– a：内联样式（）计 1
– b：ID 选择器数量
– c：类、属性、伪类选择器数量
– d：元素、伪元素选择器数量
例如：#header .nav-item.active:hover 权重是 (0,1,3,1)；div#main ul li a 是 (0,1,0,4) —— 前者胜出，尽管后者更长。
- 伪类如
:is()、:where()内部选择器不参与权重累加，:is(.a, .b)权重 =(0,0,1,0) -
[class="foo"]是属性选择器（+1c），而.foo是类选择器（也+1c），权重相同，但实际匹配行为不同 - 用浏览器开发者工具的“Computed”面板看“specificity”值，比肉眼判断可靠得多
@import 会阻塞渲染且改变层叠上下文
@import 在 CSS 文件中使用时，不仅带来额外 HTTP 请求（尤其未开启 HTTP/2），还会让被导入的样式**在语法上视为出现在 @import 声明位置**，而非物理文件末尾。
陷阱案例：在 theme.css 开头写 @import "base.css";，再写 button { color: red; }，你以为 base.css 里的 button { color: blue; } 会被覆盖 —— 实际上，因为 @import 是同步解析的，base.css 内容被“展开”到此处，其规则就处于你后续声明的上方，反而可能被覆盖。
- 现代项目应避免
@import，改用构建工具（如 PostCSS、Webpack）做合并 - 若必须用，确保
@import全部放在文件最开头，且不要混用@import和非@import规则 -
@import不支持媒体查询条件懒加载（@import url(x.css) screen and (min-width: 768px);会触发请求，即使不匹配）
/* 错误示范：@import 插在中间 */
body { font-size: 14px; }
@import "reset.css";
button { color: red; } /* reset.css 里的 button 规则实际在这里“插入”，可能被上面的 body 影响？不，但顺序已乱 */真正难处理的，往往是权重相同、来源分散（第三方库 + 自定义 + 内联）、又带动态类名的场景。这时候靠猜不如打开 DevTools 的 Styles 面板，逐条看「strike-through」划掉的是哪条规则、为什么被干掉。
