z-index压缩后失效主因是暴露原有定位缺失或层叠上下文冲突；需确保position非static且与z-index同选择器声明，排查祖先元素opacity/transform/filter触发的stacking context，并验证Tailwind zIndex配置完整性。
压缩后 z-index 失效，几乎从不因为 CSS 压缩工具“删掉了 z-index”，而是压缩过程暴露了原本就存在的层叠上下文冲突或定位缺失——这些在未压缩时可能因样式加载顺序、浏览器解析容错或开发环境缓存而侥幸生效。
压缩后 position: static 暴露得更彻底
CSS 压缩（如 cssnano、esbuild、PostCSS）会移除冗余空格、合并重复声明、甚至按字母序重排规则，导致原本靠“后写覆盖”生效的 position 被提前或覆盖。例如：
.modal {
z-index: 999;
}
/* 未压缩时可能靠顺序生效 */
.modal.show {
position: fixed;
}
压缩后可能变成：
.modal { z-index: 999; }
.modal.show { position: fixed; }
但若另一个文件里有：
.modal { position: static; }
压缩合并后，position: static 可能排在后面，直接覆盖掉 position: fixed。
- 用 Chrome DevTools 的 «Computed» 面板查目标元素，搜
position，确认最终值不是static - 避免依赖“书写顺序”来覆盖
position，把定位声明和z-index放在同一个选择器里，比如.modal.show { position: fixed; z-index: 999; } - Tailwind 用户注意：
fixed工具类必须和z-50同时存在，不能分开写在不同 class 中再靠压缩合并
压缩后 opacity/transform/filter 触发的层叠上下文更难绕过
未压缩 CSS 中，多个规则分散、权重低，浏览器有时会因解析延迟或样式表加载时序“误判”层叠上下文边界；压缩后规则集中、优先级明确，父级 opacity: 0.99 或 transform: translateZ(0) 的触发效果变得不可回避。
- 检查所有祖先节点的
opacity、transform、filter是否在压缩后仍保留非初始值（哪怕只是opacity: 0.999） - 在 DevTools Elements 面板中逐级点击父节点，右侧面板 «Layout» 标签下看 «Stacking context» 是否为
Yes—— 压缩不会改这个逻辑，但会让它更稳定复现 - 临时在压缩后的 CSS 文件里搜索
opacity:、transform:、filter:，快速定位可疑规则
Tailwind 用户：压缩后 theme.zIndex 配置失效更明显
Tailwind v3+ 的 theme.zIndex 必须是完整对象，且键值均为字符串；压缩工具若对配置文件做 JSON 解析或预处理（如某些构建插件），极易破坏格式，导致生成的 CSS 根本不含你定义的 z-modal 类。
- 确认
tailwind.config.js中theme.zIndex是完整对象，不是只写extend： - ✅ 正确：
zIndex: { 'modal': '50', 'dropdown': '40' } - ❌ 错误：
extend: { zIndex: { 'modal': '50' } }（默认为空，extend 不生效） - 改完配置后必须重启开发服务器 —— Tailwind 不热重载
tailwind.config.js，压缩构建时若用的是旧缓存，z-modal就不会出现在输出 CSS 中 - 在压缩后的 CSS 文件里全局搜索
z-modal，确认它是否存在；不存在就说明配置没生效，不是 z-index “失效”，而是压根没生成
真正难处理的不是压缩本身，而是它像一面镜子，照出那些靠开发环境“宽容”掩盖的层叠上下文混乱、定位缺失和配置错误——修复重点永远在压缩前的语义完整性，而不是压缩后的“找补”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
