relative定位不改变文档流占位，偏移后视觉位置与原始空间分离，导致重叠；其z-index失效常因层叠上下文断裂，移动端需警惕viewport变化、字体缩放及跨设备渲染差异。
relative 定位本身不会导致重叠，但偏移后视觉位置与文档流占位分离，是重叠的直接诱因。
relative 元素仍占原始空间，但“人走了，座位还留着”
设置 position: relative 后，元素在文档流中的占位（即它原本该占据的矩形区域）完全不变。你用 top、left 移动它，只是让它“浮起来”显示在别处，而周围元素照常按它没动过的位置排布。
这就造成典型错位：比如两个 div 垂直排列，给第一个加 top: -20px，它会上移盖住第二个——但第二个根本不知道自己被盖了，因为它还在原地渲染。
- 检查是否误以为
relative能腾出空间：它不能，margin或transform才影响布局 - 移动端常见陷阱：viewport 缩放或 font-size 变化后，
top: 10px实际像素偏移变小，导致原本不重叠的元素突然贴合甚至覆盖 - 不要依赖父容器自动“撑开”：父容器高度仍由原始占位决定，不会随 relative 子元素的视觉偏移增长
移动端特别容易触发重叠的三个原因
屏幕小、交互密集、样式易受系统干预，让 relative 的“占位不变”特性更易暴露问题：
立即学习“前端免费学习笔记（深入）”；
-
font-size: 16px在 iOS Safari 中可能被强制放大（如阅读模式），导致top: 50%计算基准突变，偏移量失准 - 使用
vh单位时，iOS 滚动时地址栏收起/展开会改变视口高度，top: 20vh的实际像素值跳变，引发瞬时重叠 - 某些安卓 WebView 对
transform: translateY()和top的渲染优先级不同，同一段 CSS 在不同设备上表现不一致
z-index 在 relative 元素上失效的真正原因
写了 z-index: 999 却盖不住隔壁元素？大概率不是数值不够大，而是层叠上下文断了：
- 父容器设了
opacity: 0.99、transform: scale(1)或will-change: transform→ 隐式创建新层叠上下文，子元素的z-index只在内部比大小 - 两个 relative 元素若不在同一父容器下，它们的 z-index 不可比；必须确保它们的最近共同祖先没有
z-index（或设为auto） -
z-index: auto是默认值，等于没写；必须显式写成整数，哪怕z-index: 0
该用 relative 还是换别的方案？
判断依据不是“想不想动”，而是“动完要不要留空”：
- 仅做微调动画起点/终点：用
transform: translate()，不占位、性能好、无重叠风险 - 需要真实腾出空间给其他内容（比如按钮上移后下方露出操作区）：改用
margin-top: -20px或padding-bottom调整父容器 - 要彻底自由定位且不干扰流：父容器加
position: relative，子元素用position: absolute，此时z-index行为更可预测 - 绝对避免在滚动容器（
overflow: scroll）里对子项用 relative + 大偏移，iOS 下易触发渲染异常和点击穿透
最常被忽略的一点：移动端调试时，开发者工具的“Toggle device toolbar”模拟的是 viewport 尺寸，但无法模拟系统 UI（如 iOS 地址栏）对 vh 和 top 的实时挤压。真机连 Chrome DevTools 调试，才能看到重叠是否真实发生。
