实用教程
用 Claude Opus 5.5 修复被页头挡住的商品菜单
商品菜单即使设置了 z-index: 9999，仍可能被页头挡住。把菜单祖先节点的样式和遮挡元素一起交给 Claude Opus 5.5，让它先找出层叠边界，再提出补丁。单纯增大子元素的数字，无法让它脱离父级层叠上下文。
商品菜单即使设置了 z-index: 9999，仍可能被页头挡住。把菜单祖先节点的样式和遮挡元素一起交给 Claude Opus 5.5，让它先找出层叠边界，再提出补丁。单纯增大子元素的数字，无法让它脱离父级层叠上下文。
先区分三种相似现象
2013 年的一则社区提问询问哪些属性会建立层叠上下文。具体规则以当前 MDN 层叠上下文指南为准：变换、低于 1 的透明度，以及某些定位与 z-index 组合都可能建立上下文。仅有 position: relative，并不总会建立新上下文。
| 现象 | 需要收集的证据 | 优先修复方向 |
|---|---|---|
| 菜单落在同级页头下面 | 祖先上下文与同级排序 | 调整真正相关的父级层次 |
| 菜单恰好在卡片边缘截断 | overflow 与裁切样式 | 单独处理裁切 |
| 固定菜单跟着变换后的卡片移动 | 包含块与元素矩形 | 重新检查定位及祖先 |
| 对话框始终高于普通内容 | 是否处于浏览器顶层 | 尊重其独立层叠机制 |
用两个父级算清楚
假设一个定位卡片的 z-index 为 1，同级页头为 2，卡片内的菜单为 9999。用 [1, 9999] 与 [2] 作为解释性路径，就能看出页头在第一层比较时已经胜出。把 9999 改成 999999，不会改变这个结果。本地数字样例只验证这项简化比较，不是完整 CSS 绘制算法的浏览器实现，也不是 Opus 修复实测。
先判断卡片是否需要独立层叠上下文。只有确认视觉效果和布局不受影响后，才移除不必要的触发属性。如果菜单必须跨越这条边界，可以考虑把浮层放入合适的共享层。Portal 只改变 DOM 位置，不会自动解决坐标、裁切、事件或焦点。保留触发按钮的无障碍名称，移动后重新验证打开、关闭和键盘操作。
先证据、后补丁的提示词
检查这个商品菜单、触发按钮、直到文档根节点的全部祖先，以及遮挡它的页头。我会提供 DOM、计算后的 position/z-index/transform/opacity/overflow 和元素边界矩形。
区分层叠、裁切、包含块问题。找出第一处相关边界，用实际祖先链解释修复方案。不要整体提高所有 z-index，也不要删除所有变换。
返回保留布局、动画和无障碍名称的最小补丁。如果移动浮层，说明坐标更新、滚动行为、事件处理和焦点恢复。测试窄屏、宽屏、缩放、滚动、键盘开关及重复挂载。未执行的检查标为待验证，没有证据不要声称浏览器修复成功。这是参考官方 Opus 提示指南设计的工作流程，并未执行模型基准测试。
在真正出错的边界验收
修改前后截取同一个菜单状态。确认目标菜单可见、无关内容的顺序未乱，滚动时菜单仍对齐。即使层次比较正确，也要独立检查裁切。记录浏览器、视口和实际键盘结果。
**所有浮层都该用最大数字吗？** 不该，数字只在所属上下文中有意义。**移到 body 就一定成功吗？** 不一定，定位与交互仍须测试。模态交互请参考独立的对话框焦点指南。
商品展示正常后，可在 Panelly Studio 制作配套广告图。这里没有声称 Panelly 集成 Opus 或自动修复页面 CSS。
