position: relative微调不影响其他元素布局，因其仅视觉偏移、仍占原文档流空间；浏览器先按静态流分配空间，再渲染时应用top/left偏移，故兄弟元素照常紧贴其原始位置排布。
直接说结论：position: relative 是唯一能在不脱离文档流的前提下，用 top/left 等属性做视觉微调的方式——它动的是“画的位置”，不是“占的位置”。
为什么 relative 微调后其他元素没跟着动？
因为浏览器布局分两步：先按静态流分配空间（这一步 position: relative 不干预），再渲染时才应用偏移。所以元素视觉上挪了，但原始占位还在，.box2 依然紧贴 .box1 原来该在的地方排布。
常见错误现象：top: 10px 后发现下方文字没下移，反而被盖住了——这不是 bug，是预期行为。
- 元素仍参与盒模型计算（比如父容器高度不会塌）
-
top的基准点是它自己原本的 top 边缘，和父容器的padding或border无关 - 负值完全合法：
top: -2px往上拉，right: -5px往右推（注意方向）
什么时候该用 relative 而不是 transform？
选 position: relative + top/left，当你要：
立即学习“前端免费学习笔记（深入）”；
- 让
z-index生效（transform不会创建层叠上下文） - 作为
position: absolute子元素的定位参考（必须设relative才能生效） - 做静态修正（比如按钮里图标偏高 1px），且不需要动画
选 transform: translateY()，当你要：
- 做 hover 动画或高频交互（性能更好，只触发 compositing）
- 避免意外创建 stacking context（
relative+z-index会切断层级继承） - 偏移量依赖自身尺寸（
transform: translate(50%, 50%)比top: 50%更可靠）
容易踩的坑：z-index 和重叠问题
position: relative 本身不触发重排，但一旦加了 z-index（哪怕只是 z-index: 0），就会创建新的 stacking context——这是最常被忽略的副作用。
典型问题：弹窗里的按钮设了 z-index: 9999，却被外层遮罩盖住，往往是因为中间某层父容器无意中写了 position: relative; z-index: 1，把子元素的层级“锁死”在内部。
- 不必要就别写
z-index，普通流元素默认层级为 0 - 若必须覆盖，优先给遮挡方设
z-index: -1，而不是疯狂堆高被遮挡方 - 微调时先关掉开发者工具的“Layout Shift”提示，确认是否真有重叠，再决定要不要加
margin预留空间
真正难的不是怎么写 position: relative，而是预判偏移后的视觉落点会不会压住可点击区域或文字——它不破坏布局，但可能破坏可用性。
