层叠上下文和选择器优先级是两套独立机制：前者由position+z-index（非auto）、opacity等触发，决定z轴绘制顺序；后者仅决定哪条css规则的z-index能生效，不直接影响z轴位置。
层叠上下文和选择器优先级是两套独立机制
很多人以为“z-index高就一定在上层”，结果发现加了z-index: 999还是被盖住——问题往往出在没搞清层叠上下文（stacking context）和选择器优先级（specificity）根本不是一回事。前者决定元素在Z轴上的绘制顺序，后者只管哪条CSS规则的z-index值能生效。如果z-index本身就被更高优先级的选择器覆盖或重置为auto，再大的数值也无效。
常见错误现象：div.modal写了z-index: 1000，但父容器.page-wrapper用z-index: 1 + 更高特异性选择器（比如#app .page-wrapper）把整个子树拉进了一个低层级的层叠上下文里，导致.modal实际被限制在那个局部上下文中排序。
- 层叠上下文由
position+z-index（非auto）、opacity、transform等属性触发，一旦形成，其内部元素的z-index只在该上下文内比较 - 选择器优先级只影响“哪个
z-index声明能落地”，不直接影响Z轴位置 - 优先级冲突常发生在第三方组件库（如Ant Design）的默认样式上：它们常用
.ant-modal这类高权重类名，而你自定义的.my-modal若没加ID或组合，很可能输在c位（类选择器计数）上
:where()和:is()能绕过优先级陷阱但不改变层叠上下文
想让z-index稳稳生效，又不想硬加!important或ID，可以用:where()降权。它不参与特异性计算，权重恒为0。比如：
:where(.modal) { z-index: 1000; }
这条规则的权重是(0, 0, 0, 0)，比.ant-modal（权重(0, 0, 1, 0)）低，所以不会覆盖它；但它也不会被更低权重的规则覆盖——关键在于，它把z-index声明“让渡”给了其他更具体的规则去竞争，反而更容易被你后续写的高权重规则接管。
-
:is()相反，它取括号内所有选择器的最高权重，慎用于z-index场景，容易意外提升优先级导致覆盖失败 - 这两个伪类都不创建新层叠上下文，只影响规则匹配逻辑
- 注意兼容性：
:where()在Safari 15.4+、Chrome 105+才稳定支持，旧项目需加回退
ID选择器会强制创建新层叠上下文且权重碾压类名
给弹窗加id="modal-overlay"再写#modal-overlay { z-index: 2147483647; }，看似粗暴，但它是少数能同时解决两个问题的手段：既用ID的b位权重（(0, 1, 0, 0)）确保z-index不被覆盖，又因position: fixed + 非auto z-index自动创建根层叠上下文，跳出父容器限制。
- 但要注意：ID必须唯一，动态渲染的模态框（如React多实例）不能共用同一ID，否则破坏HTML规范且DevTools调试困难
- 更安全的做法是用
[data-modal]属性选择器替代ID，权重同为(0, 0, 1, 0)，但语义清晰、可复用 - 别忘了检查父级是否用了
transform或will-change——这些也会隐式创建层叠上下文，可能把你精心设置的z-index锁死在局部
伪类:hover和:nth-child()计入类选择器权重位
写.dropdown:hover .menu { z-index: 9999; }时，:hover和.menu都算作c位（类/伪类），总权重是(0, 0, 2, 0)。这比单纯.menu（(0, 0, 1, 0)）高，但依然打不过#nav .menu（(0, 1, 1, 0)）。很多人误以为伪类“不算权重”，结果悬停时菜单还是被盖住。
-
:nth-child(n)、:not()、:focus-within全属伪类，全部计入c位，不是零权重 -
::before、::after是伪元素，只影响d位（(0, 0, 0, 1)），对z-index控制无直接帮助 - 真正要小心的是
:has()——它目前不参与权重计算（草案阶段），但一旦支持，它的选择器内容仍会按常规规则累加权重
z-index的生效值和它所处的层叠上下文层级——这两者得一起看，缺一不可。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
