题干与适用场景
一个产品页面包含吸顶导航和带菜单按钮的卡片。菜单采用绝对定位，并设置了一个非常大的 层叠值。它在页面顶部附近展开时，导航仍然会盖在菜单上面；它超出卡片边界时，下半部分又会 消失。有同事建议在层叠值后面再加一个零。
请解释这个方案为什么无法同时解决两个现象。诊断下面的示例，区分绘制顺序、裁剪和定位坐标， 并针对三种情况选择可长期维护的修复：菜单可以留在组件内部、浮层必须逃离组件边界，以及交互 语义适合模态框或弹出层。
<header class="site-header">Navigation</header>
<main class="page">
<section class="card">
<button type="button">Open menu</button>
<div class="menu">Menu items</div>
</section>
</main>.site-header {
position: sticky;
top: 0;
z-index: 4;
}
.page {
position: relative;
z-index: 1;
}
.card {
position: relative;
overflow: hidden;
transform: translateZ(0);
}
.menu {
position: absolute;
inset-block-start: 100%;
z-index: 999999;
}假设目标环境是当前主流浏览器。答案应保留有意设计的滚动、包含和无障碍行为，不能为了让一张 截图看起来正常就不断删除 CSS。
面试官考察点
第一项信号是候选人能否找对比较边界。一个层叠上下文会作为原子整体参与父级上下文的绘制。 后代可以在这个整体内部重新排序，但后代的任何层叠值都不能把整个父级上下文抬到其兄弟之上。 在本题中，菜单的超大值只在 .page 内部胜出；.page 整体仍以层级 1 参与比较，低于层级 4 的导航。
第二项信号是问题分类。“被导航压住”属于绘制顺序问题；“在卡片边缘消失”属于 overflow: hidden 造成的裁剪问题。还有一类外观相似的问题：带变换的祖先会为绝对定位和固定 定位的后代建立包含块，导致坐标或固定行为相对了错误的祖先。一个层叠值无法修复裁剪和坐标。
第三项信号是理解层叠上下文的创建原因，而不是背诵一张清单。常见原因包括：定位元素设置非 auto 层叠值、固定或粘性定位、小于一的不透明度、变换、滤镜、透视、裁剪或遮罩、混合模式、 isolation: isolate、布局或绘制包含、容器查询，以及设置非 auto 层叠值的 flex 或 grid 子项。真正有用的能力是沿两条祖先链找到第一个相关边界。
第四项信号是修复判断。移除意外创建的上下文、调整正确祖先的层级、重新挂载浮层和使用浏览器 顶层，解决的是不同契约。Portal 能改变 DOM 祖先关系并避开组件裁剪，但不会自动进入顶层，也 不会自动提供模态语义、焦点、关闭或无障碍名称行为。
最后一项信号是验证。除了在开发者工具中检查，还应通过真实重叠点、滚动、尺寸变化、缩放、 键盘和其他浮层共存来验证。如果修复只赢了一张截图，却破坏滚动容器、绑定到错误坐标系，或者 让普通菜单盖住真正的模态框，答案仍然不完整。
回答前需要澄清的问题
- 具体哪些像素不对？ 菜单是绘制在另一个元素下面、在某个边界被裁剪、坐标错误，还是被
顶层元素覆盖？这些问题需要不同修复。
- 哪些祖先创建了上下文？ 同时检查菜单和遮挡元素的祖先链。真正的比较发生在两条链首次
成为兄弟的位置，不一定发生在两个可见元素本身。
- 裁剪是否有意为之？ 卡片可能需要裁剪圆角媒体，滚动容器也可能依赖 overflow。全局移除
它可能修好菜单，却破坏布局和滚动。
- 浮层应锚定在哪里？ 重新挂载到共享浮层根节点后，需要相对该根节点测量坐标，并在滚动、
调整窗口、缩放和布局变化时更新。
- 交互是否需要顶层语义？ 模态框应阻止外部交互并管理焦点；轻量菜单可能只需共享浮层根；
合适的弹出内容可以使用平台的 popover 行为和顶层位置。
- 哪些浮层可以共存？ 明确菜单、提示、吸顶导航、抽屉和模态框能否相互覆盖。少量命名层级
比任意六位数更容易推理。
- 浏览器和组件契约是什么？ 当前平台原语通常更合适；旧版 WebView 或已有设计系统原语可能
改变实现选择。
30 秒回答框架
“我会先给故障分类，再改数值。菜单的 999999 只在自己的层叠上下文内比较。它的祖先 .page 是层级 1，所以整个子树仍然低于层级 4 的吸顶导航。卡片的隐藏溢出又会单独裁剪 菜单，而变换可能改变菜单的包含块。我会检查两条祖先链，并确认重叠点实际位于最上方的元素。 如果菜单可以留在局部，就移除意外上下文或调整正确祖先，并把裁剪限制在需要它的子元素。如果 必须逃离组件，就渲染到共享浮层根节点并重新维护锚点坐标。如果交互是模态框或合适的 popover， 就使用浏览器顶层并实现相应焦点和关闭契约。最后验证滚动、尺寸变化、缩放、键盘和其他浮层共存。”
分步骤深入解答
先把四种机制分开。它们可能同时失败，但不能互相替代：
PAINT ORDER
Which painted box is above another?
Controlled by the stacking-context tree and paint order inside each context.
CLIPPING
Which pixels are allowed to appear?
Controlled by overflow, clip paths, masks, and paint containment.
GEOMETRY
Which box supplies the coordinate system?
A transform can establish the containing block for absolute and fixed descendants.
TOP LAYER
Is the element outside normal document stacking?
Modal dialogs and shown popovers can be placed in the browser-managed top layer.为示例构建上下文树，不能只比较两个可见数值。吸顶导航创建层级 4 的上下文；定位的 .page 创建层级 1 的兄弟上下文；卡片的变换又在 .page 内创建一个上下文。菜单的超大值只在这个 子树内部排序。概念上，比较的是 header: 4 与 page: 1，浏览器不会直接比较 header: 4 和 menu: 999999。
随后独立检查裁剪。菜单是 .card 的后代，超出卡片内边距框的像素会被隐藏溢出裁掉。层叠只 改变绘制顺序，不会扩大裁剪区域。抬高 .page、移除变换或改变菜单数值，都可能让它高于导航， 但下半部分仍然消失。
接着检查包含块。菜单采用绝对定位，因此已定位的卡片本来就提供其坐标。对当前菜单而言，变换 是多余的；但如果未来实现把菜单改成 position: fixed，变换祖先可能让这个“固定”元素相对祖先 而非视口定位。因此，把绝对定位改成固定定位不是可靠的逃生通道。
用浏览器检查验证推断，避免猜测。检查每个祖先的计算样式，直到找到第一个上下文创建者和裁剪 祖先；比较菜单与导航的上下文链；再在发生重叠的坐标查询命中测试认定的最上层元素：
function inspectOverlap(x, y) {
const stack = document.elementsFromPoint(x, y)
return stack.map((element) => ({
element,
position: getComputedStyle(element).position,
zIndex: getComputedStyle(element).zIndex,
overflow: getComputedStyle(element).overflow,
transform: getComputedStyle(element).transform,
}))
}elementsFromPoint() 便于查看命中测试栈；elementFromPoint() 只返回最上方符合条件的元素。 命中测试是辅助证据，不是完整的层叠上下文调试器：设置 pointer-events: none 的元素可能被跳过， 裁剪或位于屏幕外的坐标仍需检查布局。
根据所有权边界选择影响最小的修复。
对于局部菜单，如果某个上下文没有必要的视觉或包含作用，就移除这个意外边界。如果页面确实 需要自己的上下文，应比较并调整页面级 token，因为参与导航比较的是这个兄弟。如果卡片裁剪只 用于媒体，把裁剪下沉到媒体包装层，不要让整张交互卡片负责裁剪。
:root {
--layer-content: 0;
--layer-sticky: 20;
--layer-overlay: 40;
}
.page {
position: relative;
z-index: var(--layer-content);
}
.site-header {
z-index: var(--layer-sticky);
}
.card-media {
overflow: hidden;
border-radius: 1rem;
}
.menu {
z-index: var(--layer-overlay);
}这个方案只适用于页面子树可以继续位于导航下面、菜单不必跨越该边界的契约。如果菜单必须覆盖 导航，层级决策就属于共同祖先，或者浮层需要移动到共享根节点。
对于必须逃离局部上下文和裁剪的可复用浮层，把它渲染到接近文档根的共享浮层根节点。触发器 仍是逻辑所有者，保留无障碍关联，并根据触发器矩形计算面板位置。滚动、窗口尺寸、缩放或布局 变化使任一矩形变化时都要重新计算；碰撞处理还要考虑视口边缘和书写方向。只重新挂载而不接管 坐标，会把裁剪问题换成菜单漂移问题。
对于真正的模态框，优先使用以模态方式打开的原生 dialog 元素，或者提供同等契约的成熟无障碍 原语。对于合适的非模态交互，popover API 可以把已显示的内容放入顶层。顶层条目绘制在普通 文档上下文之上，后进入的条目位于先进入的条目上方，每个条目都有自己的根层叠上下文。祖先的 overflow、不透明度、遮罩和变换不会把顶层元素重新拉回祖先的文档上下文。
顶层并不是“更强的 z-index”。它是由浏览器管理、通过特定机制进入和退出的有序层。模态框仍需 有可用名称、明确的初始焦点、受限的交互、关闭策略和焦点恢复。菜单仍需正确的菜单或展开语义 以及键盘行为。选择层级不能替代选择交互模型。
按矩阵验证修复：
- 在每个视口边缘和嵌套滚动容器内打开浮层。
- 分别滚动页面和最近容器，确认面板持续锚定，或按产品策略关闭。
- 调整窗口、缩放到 200%，并测试窄屏和宽屏布局。
- 使用键盘导航，确认顺序、可见焦点、Escape 和焦点返回符合组件契约。
- 分别与吸顶导航、抽屉、提示和已打开的真正模态框共存。
- 在被遮挡像素处检查命中测试，确认没有不可见浮层拦截无关控件。
- 在产品支持时测试长翻译文案、从左到右和从右到左布局。
- 确认原本有意设计的 overflow、contain、合成和滚动行为仍正常。
高质量示范回答
“超大数值在错误层级参与比较。菜单位于 .page 层叠上下文中，而这个上下文以层级 1 参与 父级比较；导航是层级 4 的兄弟上下文。浏览器把页面子树作为整体绘制在导航下面，所以后代的 999999 无法逃离并与导航竞争。
这里还有独立的裁剪故障。卡片的隐藏溢出会移除边界外的像素；z-index 只改变顺序，不能扩大 裁剪区域。卡片变换还会创建另一个上下文，并可能为绝对定位和固定定位后代建立包含块，所以改用 固定定位仍可能落在意外坐标系中。
我会在开发者工具中检查两条祖先链，找到第一个上下文和裁剪创建者，并检查重叠坐标的命中测试 栈。对于局部菜单，我只会移除意外上下文、把裁剪下沉到媒体包装层，或者调整实际参与比较的 共同祖先上的命名层级，不会继续增大叶子节点数值。
如果菜单的产品契约允许它跨越组件和导航边界，我会把它渲染到共享浮层根节点。这意味着浮层 系统需要负责测量、碰撞处理，以及滚动、尺寸、缩放和布局变化时的更新。Portal 有助于改变祖先 关系并逃离裁剪，但不会创建顶层或无障碍行为。
如果交互是模态框，我会使用原生模态 dialog 行为或经过验证的无障碍原语；如果是合适的 popover， 会考虑平台 popover 行为。两者都可以使用浏览器顶层，但仍需实现正确的无障碍名称、焦点、键盘、 关闭和恢复契约。最后我会验证滚动容器、视口边缘、200% 缩放、键盘、翻译布局、命中测试以及 与其他浮层共存。”
常见错误
- 不断增大后代数值 → 它仍被困在更低的父级上下文 → **比较首个兄弟上下文，并修改真正拥有
层级决策的节点。**
- 把所有消失像素都当作层叠问题 → overflow 或绘制包含仍然裁剪 → **把裁剪祖先与绘制顺序
分开检查。**
- 把绝对定位改成固定定位 → 变换祖先仍可能定义包含块 → 选择定位模式前先追踪坐标系。
- 删除所有 transform 或 overflow → 圆角媒体、滚动、包含或渲染行为被破坏 → **只移除意外
触发器，或把它缩小到真正需要的元素。**
- 把每个浮层都 portal 到 body → 锚定、碰撞、所有权和焦点问题替代原故障 → **使用明确管理
坐标与交互契约的共享浮层系统。**
- 认为 portal 就是顶层 → 普通文档上下文仍可能覆盖它 → 在语义匹配时使用平台顶层原语。
- 所有浮动面板都使用模态框 → 焦点和外部交互被不必要地阻断 → **先按行为选择模态框、
popover、菜单、提示或行内展开。**
- 创建任意全局大数值 → 组件开始层级军备竞赛 → 使用少量命名层级，并让局部数值保持局部。
- 只验证一张截图 → 滚动、缩放、键盘或另一个浮层会重新暴露问题 → 测试完整重叠与交互矩阵。
追问及应对
更大的 z-index 一定会位于更小的值上面吗？
只有两个值参与同一个相关层叠上下文比较时才成立。后代先在自身上下文内排序，整个上下文再到 父级排序。应比较上下文链，不能只看孤立的计算值。
哪些 CSS 属性经常创建层叠上下文？
根元素、固定或粘性定位、设置非 auto 层叠值的定位元素、小于一的不透明度、变换、滤镜、透视、 裁剪或遮罩、混合、隔离、部分包含和容器查询属性，以及设置非 auto 层叠值的 flex 或 grid 子项都很常见。具体列表会演进，因此排查时应找出实际计算样式触发器，不能只依赖记忆。
为什么元素能盖住兄弟，却仍然像被切掉一样？
绘制顺序决定允许出现的像素谁最后绘制；裁剪区域决定哪些像素获准出现。即使赢得绘制顺序， 也无法找回被祖先 overflow、clip path、mask 或绘制包含移除的像素。
position: fixed 一定能逃离 overflow-hidden 祖先吗？
不能。固定定位改变通常的包含块行为，但祖先的变换及相关属性仍可能建立包含块，其他裁剪机制 也可能继续生效。应追踪坐标和裁剪，不能把固定定位当成通用逃生方案。
通过 Portal 渲染能解决全部问题吗？
如果目标根位于局部上下文和裁剪之外，它可以逃离这些 DOM 祖先限制，但也引入新的测量、滚动 更新、碰撞、事件关联、焦点和关闭所有权。除非原语自身进入顶层，否则它仍在普通文档层叠中。
顶层与一个很大的全局层级 token 有什么区别？
顶层元素绘制在浏览器管理、位于普通文档内容上方的有序层中，并创建根层叠上下文；进入顺序 决定顶层内部顺序。很大的全局 token 仍参与文档上下文树，也可能被祖先困住。
团队是否应该禁止所有局部 z-index？
不应该。局部值适合排列同一组件内部的元素，例如让徽标盖在图片上。只在吸顶导航、可复用浮层、 抽屉等共享边界使用少量命名尺度。一个值是否全局取决于边界，不取决于数字大小。
如何防止这类问题回归？
记录少量共享层级的所有者，集中管理可复用浮层位置，并建立同时包含吸顶内容、滚动容器、菜单和 模态框的交互场景。验证边缘位置、滚动、缩放、键盘和另一个活跃浮层；静态截图无法证明契约。