定位元素“消失”八成是被 overflow 裁剪，真正裁剪者是最近的定位祖先（非直接父级），而非元素被删除；常见于 modal、carousel、Tab 根节点等容器设了 overflow: hidden/auto/scroll 且高度固定；需逐级检查 computed overflow 和 height，临时移除可疑 overflow 即可验证。
定位元素“消失”八成是被 overflow 裁剪了
它没被删，只是像素被切掉了。真正起作用的不是直接父级，而是它的定位祖先（即最近的 position: relative/absolute/fixed/sticky 祖先）。只要这个祖先设置了 overflow: hidden、overflow: auto 或 overflow: scroll，且自身高度固定、内容未溢出，就会把超出边界的 absolute 子元素视觉裁剪掉。
常见藏雷区包括：.modal-wrapper、.carousel-container、Tab 切换根节点、卡片外层、甚至 body 上的全局 overflow: hidden。别只查父级，要往上点到 body，逐级看 Computed 面板里的 overflow 和 height 值。
- 临时删掉可疑节点的
overflow声明，元素立刻回来 → 就是它 - Flex/Grid 容器默认触发 BFC，加了
overflow: hidden后会裁剪内部absolute元素 -
transform: translateZ(0)或will-change: transform可能意外让父级变成裁剪边界
iOS Safari 和安卓 WebView 下 absolute/fixed 突然不见
这不是渲染失败，是 GPU 合成层切断了定位上下文关联。典型诱因是 backface-visibility: hidden —— 它在 Android 9–11 和 iOS Safari 15.x–16.2 中会强制创建独立合成层，导致 absolute 找不到包含块、fixed 锚定失效，最终被跳过绘制。
现象很典型：Elements 面板里元素高亮正常，但 Computed 样式中 display 显示为 none，或位置计算为空；截图里完全空白。
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools 搜索
backface-visibility，从目标元素往上逐级查父容器 - 临时设为
backface-visibility: visible或直接删掉，刷新验证 - 替代方案优先选
transform: translateZ(0.001px)或contain: layout paint，比硬套hidden更稳妥
打印时 position: fixed 元素彻底不渲染
这不是 bug，是 CSS Paged Media 规范明确要求：打印没有“视口”，position: fixed 失去锚点，浏览器压根不进入定位计算流程——加 !important 也没用。
只写 position: static !important 是危险的。残留的 top、z-index、transform 仍参与样式计算，可能引发偏移或层叠错乱。
- 必须一并重置：
position、top、right、bottom、left、z-index、transform、will-change - 页眉页脚改用
@page :first { @top-center { content: "标题"; } }，别靠@media print强撑fixed - 弹窗、Tooltip 类组件建议打印前统一
display: none !important
移动端滚动时 absolute 元素“飘走”或消失
核心问题有两个：一是它锚定的不是你认为的那个父容器，二是那个父容器被 overflow 裁剪了。iOS Safari 还额外要求合成层写法双保险。
如果滚动容器只写了 overflow-y: auto 和 height: 400px，但没设 position: relative，那 absolute 元素就会上溯到 body 定位，一滚动就跑偏。
- 给滚动容器加
position: relative（副作用最小） - iOS Safari 下，
absolute元素需同时写-webkit-transform: translate3d(0,0,0)和transform: translate3d(0,0,0) - 避免父容器
z-index设得过大（如9999），iOS 对超大值排序不稳定 - 别用
will-change: transform—— 它可能加重内存压力，还破坏position: sticky行为
absolute 元素到底锚在哪，以及谁在裁它。这两点没理清，所有修复都是临时止痛。 
