根本原因是 transform、opacity 或 will-change 等属性意外触发层叠上下文，导致子菜单 z-index 仅在局部生效；iPad Safari 对层叠上下文创建更敏感，需检查并移除相关属性或显式重置父容器层叠行为。
HTML5 页面在 iPad 上菜单层级错乱，根本原因几乎总是 z-index 计算被 transform、opacity 或 will-change 等属性意外触发的层叠上下文（stacking context）打断，而非 z-index 值本身写错了。
为什么 iPad Safari 的 z-index 表现和桌面 Chrome 不一样
iPad（尤其是 iOS 15+）Safari 对层叠上下文的创建更敏感，且渲染管线对合成层（composited layer）的判断逻辑与桌面不同。一个看似无害的 transform: translateZ(0) 或 opacity: 0.99 就会让父元素提前建立新的层叠上下文，导致其子菜单的 z-index 只在该局部上下文中生效，无法盖过页面其他区域的元素。
- 检查所有菜单容器及其父级是否无意中加了
transform（哪怕只是translate3d(0,0,0)）、opacity、filter、will-change - 用 Safari 开发者工具（连接 Mac 的 Web Inspector）选中错位菜单，看「Computed」面板里
z-index是否显示为auto，并留意「Stacking Context」提示 - 临时移除疑似属性后刷新测试——比改
z-index数值有效得多
菜单弹出层被遮挡但 z-index 值明明很大
常见于使用 position: fixed 或 position: absolute 的下拉菜单，实际渲染时被轮播图、导航栏或模态框的某个祖先节点截断了层叠范围。
- 确保菜单最外层容器的直接父元素没有创建新层叠上下文；必要时给该父元素显式加
z-index: 0并设position: relative，强制它成为「中性」层叠容器 - 避免在菜单父级上用
backface-visibility: hidden—— 它在 iOS Safari 中会隐式触发层叠上下文 - 如果菜单是动态插入 DOM（如 Vue/React 组件挂载），确认它插入位置在
底部，而非嵌套在某个低 z-index 的模块内部
使用 CSS @media 检测 iPad 时的陷阱
别依赖 @media (max-width: 1024px) 或 screen and (orientation: portrait) 来单独修复 iPad 层级问题——这些规则在桌面浏览器缩放时也会命中，造成误判；而且 iPad Pro（12.9"）的 viewport 宽度可能达 1366px，根本不会进规则。
立即学习“前端免费学习笔记（深入）”；
- 真正可靠的检测方式是结合
userAgent+platform，但仅用于加载轻量级修复 CSS（不用于核心布局） - 更稳妥的做法：统一用
z-index: 9999级别给所有可交互浮层（菜单、tooltip、toast），并在全局重置关键父容器的层叠行为 - 在 CSS 中加一句：
body > * { transform: none !important; opacity: 1 !important; filter: none !important; }，再针对性放开需要动效的元素，能快速定位是否是某处全局样式污染所致
最常被忽略的是：iOS Safari 对 z-index 的解析严格依赖 DOM 顺序 + 层叠上下文链。即使数值再大，一旦被包进一个意外创建的上下文里，就彻底出局。动手前先打开 Web Inspector 看「Layers」面板，比猜更准。
