Bootstrap的z-index生效关键在于理解层叠上下文、对齐官方预设值（如$zindex-modal:1055）、确保父容器定位且未创建隔离上下文，而非盲目写大数。
直接说结论：Bootstrap 的 z-index 不是靠“写大数”管用的，而是靠理解层叠上下文（stacking context）+ 对齐官方预设值 + 控制父容器定位状态。硬塞 z-index: 9999 只会让后续加 .toast、.tooltip 或第三方组件时彻底失控。
为什么你改了 z-index 还是被盖住
常见错误现象：.dropdown-menu 明明写了 z-index: 2000，却仍被 .modal 截断；自定义弹窗在 .navbar 内展开后只显示半截。
- 目标元素没定位：
z-index对position: static（默认）完全无效，必须加position: relative或其它定位值 - 父容器悄悄创建了层叠上下文：比如
.navbar用了transform动画、.accordion-item加了opacity: 0.99、甚至will-change: transform，都会让子元素的z-index只在它内部生效 - 你调的是子元素，但“天花板”在父级：例如
.modal的z-index: 1055创建了强隔离上下文，里面所有子元素再高也出不去——得先确保它的父容器（如.modal-content）本身有足够高的z-index
如何对齐 Bootstrap 官方 z-index 体系
Bootstrap 5.3 的关键变量在 node_modules/bootstrap/scss/_variables.scss 里，CDN 用户可查官方 CSS 注释块（搜索 zindex）。别猜，直接看真实值：
$zindex-dropdown: 1000$zindex-sticky: 1020$zindex-fixed: 1030$zindex-modal-backdrop: 1040$zindex-modal: 1055$zindex-tooltip: 1070$zindex-toast: 1080
使用场景：你要让自定义下拉菜单盖过 .navbar（z=1000）但低于 .modal（z=1055），那就设 z-index: 1025；若要盖过 .modal，父容器至少得 z-index: 1056，且不能被更上层上下文包裹。
立即学习“前端免费学习笔记（深入）”；
怎么安全地覆盖并长期维护
硬写 !important 或行内 style="z-index: 9999" 是短期止痛，后期升级或引入新组件必崩。
- 用 Sass 编译项目：在引入 Bootstrap 前重定义变量，例如
$zindex-modal: 1100，所有依赖自动对齐 - 用 CDN 但想可控：在自定义 CSS 中用更具体选择器覆盖，例如
.my-app .dropdown-menu { z-index: 1060; }，并确保该 CSS 在 Bootstrap 之后加载 - 统一收口到 CSS 自定义属性（Bootstrap 5.3+ 支持）：
:root { --bs-zindex-modal: 1100; }，部分组件会读取该变量 - 避免污染全局：不写
.dropdown-menu { z-index: ... }，而限定作用域，如.admin-layout .dropdown-menu
哪些地方最容易被忽略
真正卡住问题的，往往不是 z-index 数值本身，而是这些隐性条件：
-
transform、opacity 、<code>filter、will-change这些属性会静默创建层叠上下文——哪怕只加在父级的父级上，也会向下传递影响 - 移动端 iOS Safari 对
position: fixed的处理极不稳定，一旦其祖先有transform，fixed 就退化为 absolute，层级和定位基准全乱 -
.dropdown-menu默认没有z-index，它靠文档流堆叠；嵌套在.accordion或.card里时，必须给父级（如.accordion-item）加position: relative和递增z-index，否则兄弟项会互相遮挡 - JS 组件（如 CKEditor、Select2）自带 z-index，它们通常不会读 Bootstrap 变量，得手动在项目 CSS 中显式覆盖，并检查其 DOM 挂载位置是否被某层 transform 容器包裹
