z-index在媒体查询中不起作用的直接原因是它只对定位元素生效，若未同时设置position（如relative），则被忽略；需检查层叠上下文、合理使用display/visibility控制显隐，并注意移动端兼容性问题。
z-index 在媒体查询里为什么不起作用
直接原因：z-index 只对「定位元素」生效，而很多人在媒体查询中给普通 div 加 z-index，却忘了加 position: relative 或其它定位值。
常见错误现象：@media (max-width: 768px) { .sidebar { z-index: -1; } } —— 完全没效果，因为 .sidebar 默认是 position: static，此时 z-index 被忽略。
- 必须同时设置
position（哪怕只是position: relative）才能激活z-index - 媒体查询中修改
z-index时，优先检查父容器是否形成了新的层叠上下文（比如有opacity: 0.99、transform、will-change等），否则子元素的z-index会被截断 - 移动端常用场景：折叠菜单弹出时盖住内容，需确保弹层的
z-index高于主内容区，且两者都有明确的position
响应式显示优先级该用 z-index 还是 display/visibility
z-index 控制的是「谁在上面」，不是「要不要显示」；真正决定显示优先级的，往往是 display、visibility 和 DOM 顺序本身。
比如在小屏下隐藏侧边栏、让主内容占满宽度，靠的是 display: none 或 visibility: hidden，而不是调高主内容的 z-index。强行用 z-index 模拟显示控制，容易引发点击穿透、焦点错乱、可访问性问题。
立即学习“前端免费学习笔记（深入）”；
-
display: none彻底移出渲染流，适合彻底隐藏不参与交互的模块 -
visibility: hidden保留占位，适合需要动画过渡或保持布局稳定的场景 -
z-index仅用于多层重叠时的视觉层级协调，例如模态框、下拉菜单、固定导航栏 - 性能提示：频繁切换
z-index不影响重排重绘，但滥用层叠上下文（尤其带transform的容器）可能触发额外合成层，增加内存开销
移动端 z-index 常见兼容性陷阱
iOS Safari 对层叠上下文的处理比桌面端更敏感，尤其在使用 transform、opacity 或 filter 后，容易意外创建隔离的层叠环境，导致预期外的遮挡关系。
典型错误：给轮播图容器加了 transform: translateZ(0) 做硬件加速，结果发现顶部的返回按钮被盖住了——因为按钮和轮播图不再属于同一层叠上下文。
- 检查所有设置了
z-index的元素，确认它们的最近共同祖先没有意外创建层叠上下文 - 避免在父容器上滥用
transform或opacity ，除非你明确需要隔离渲染 - 调试技巧：在 Safari 开发者工具中勾选「Layers」面板，直观查看合成层分布
- 安卓 WebView 表现相对稳定，但低版本（如 Android 4.4）对
z-index层级深度支持有限，超过 2–3 层嵌套可能出现错乱
如何用媒体查询 + z-index 实现“视觉优先级切换”
真实需求常是：小屏下把操作按钮提到最前，大屏下让它退居次要位置。这不是简单改一个值，而是配合结构与定位策略的整体调整。
示例场景：卡片式列表，每张卡片右上角有「收藏」按钮，大屏下它偏右靠上；小屏下希望它固定在视口右下角并置顶。
- 小屏规则中，先用
position: fixed把按钮脱离文档流，再设z-index: 1000（注意：必须高于页面其他fixed元素，比如导航栏通常用z-index: 999） - 大屏规则中，还原为
position: absolute或relative，z-index设为1即可，无需清空 - 关键细节：
z-index是整数，不要写成z-index: auto或z-index: initial来“重置”，这会导致它回到默认层叠顺序，行为不可控 - 如果多个响应式组件共用同一套
z-index数值体系（如弹窗、提示条、加载遮罩），建议用 CSS 自定义属性统一管理：:root { --z-modal: 1000; --z-toast: 950; }，便于维护
复杂点在于层叠上下文的嵌套关系没法靠媒体查询自动“扁平化”，一旦父容器成了层叠上下文，子元素的 z-index 就只能在它的内部排序——这点最容易被忽略，也最难调试。
