z-index不生效的主因是元素未定位或父容器创建了新层叠上下文；须设position:relative等、避免transform/opacity
z-index 不生效？先检查父容器的定位上下文
很多卡片叠不起来，不是 z-index 设得不够大，而是它根本没被浏览器当回事。CSS 的 z-index 只对「定位元素」有效——也就是 position 值为 relative、absolute、fixed 或 sticky 的元素。如果卡片本身是 static（默认值），哪怕写 z-index: 9999 也完全无效。
常见错误现象：z-index 写了但层叠顺序没变，或者后加的卡片反而被盖住。
- 每个需要参与层级控制的卡片必须显式设置
position: relative（最常用，不影响文档流） - 避免在父容器上误加
transform、opacity 或 <code>will-change——这些会触发新的层叠上下文（stacking context），导致子元素的z-index只在该父容器内比较，不再和外部卡片竞争 - 如果用了
flex或grid布局，别指望靠order属性控制视觉层叠；它只改渲染顺序，不改绘制层级
卡片逐级偏移：用 transform 替代 top/left 更安全
想让上层卡片“浮起来一点”，很多人直接写 top: -8px，但这会破坏文档流、可能引发父容器高度塌陷或兄弟元素错位。更稳妥的做法是用 transform: translateY(-8px) ——它不改变布局空间，只影响绘制位置，且硬件加速友好。
使用场景：带阴影的卡片组、时间线、堆叠式仪表盘模块。
立即学习“前端免费学习笔记（深入）”；
-
transform不会触发重排（reflow），性能比top/left更好 - 配合
z-index使用时，确保transform元素仍是定位元素（即已设position: relative） - 注意：不要对同一个元素同时用
top和transform，行为不可预测；优先选transform
z-index 数值怎么设才不容易乱？用固定步长+语义分组
随手写 z-index: 1、2、99、9999 看似简单，实际协作中极易冲突。尤其当多个组件独立开发、又嵌入同一页面时，谁也不知道别人用了多少。
参数差异：数值本身无单位，但大小决定绘制顺序；相同 z-index 下，DOM 后出现的元素在上层。
- 按功能分组预留区间：比如弹窗类用
1000–1999，卡片组用200–299，导航栏用100，底层内容用0 - 同一组内用固定步长（如
10）：第一张卡z-index: 200，第二张210，第三张220……留出空档方便中间插入 - 避免用
z-index: 999999这类“终极值”——它往往暴露了设计失控，后续真要盖它就只能靠 JS 强行改样式了
阴影与层级错觉：box-shadow 不等于 z-index 效果
给卡片加 box-shadow 很容易让人误以为“它已经浮起来了”，但阴影只是绘制效果，不影响真实层叠顺序。两张卡片即使阴影再厚，如果下层卡片的 z-index 更高，它依然会盖住上层。
性能影响：大面积模糊阴影（尤其是多层叠加时）会显著增加合成层开销，低端设备可能出现卡顿。
- 阴影颜色建议用半透明白色/黑色（如
rgba(0,0,0,0.08)），避免纯黑导致视觉过重 - 若需强化“悬浮感”，把
transform: translateY(-2px)和轻微阴影组合使用，比单靠阴影更可信 - 绝对不要靠加大
box-shadow模糊半径来模拟层级——那只是障眼法，交互时（比如 hover 放大）立刻露馅
真正难的不是叠几层，而是让每层都清楚自己属于哪个层叠上下文、不意外创建新上下文、也不被别人的上下文吞掉。稍不注意，z-index 就从工具变成陷阱。
