position: relative 移动元素时父容器高度不变，因为元素仍在文档流中占位；top/left 相对于自身原位置计算，不依赖父容器padding/border；微调优先用 transform 性能更好，静态修正可用 relative；设 z-index 会创建层叠上下文，需谨慎使用。
用 position: relative 移动元素时，为什么父容器高度没变？
因为 position: relative 不会让元素脱离文档流——它只是“视觉上”偏移，原始占位空间还在。父容器按原来的位置和尺寸计算高度，所以不会塌陷或重排。
常见错误现象：top: 20px 后发现下方元素没跟着下移，还以为没生效；其实是它“盖”在原位置上方了，但底下的元素还当它在老地方。
- 只改
top/left，不加transform或margin，就不会触发重排（layout），性能更轻量 - 如果需要让后续元素也响应偏移（比如真正腾出空隙），得配合
margin或改用position: absolute（但会脱离流） - 注意：
z-index在relative下有效，但只对同层定位元素起作用；没设z-index的普通元素层级默认为 0
top 和 left 的值是相对于谁计算的？
相对于它自己原本在文档流中的位置，不是父容器边界。哪怕父容器有 padding 或 border，也不影响这个基准点。
使用场景：微调图标对齐、修正表单控件垂直居中偏差、小范围错位修复（比如按钮文字偏高 1px）。
立即学习“前端免费学习笔记（深入）”；
- 负值合法：
top: -3px往上拉，left: -2px往左推 - 单位必须明确，
top: 5无效，要写成top: 5px或top: 0.2em - 百分比值基于自身尺寸（不是父容器），
top: 10%表示向上移动自身高度的 10%，一般少用
和 transform: translateY() 比，哪个更适合微调？
纯视觉微调选 transform；需要参与布局或 z 轴控制选 relative + top/left。
性能差异明显：transform 只触发动画帧（compositing），不触发 layout 和 paint；而 top 改变虽不重排，但某些浏览器仍会重绘整块区域。
-
transform: translateY(2px)更适合动画或高频交互（如悬停微移） -
position: relative; top: 2px更适合静态修正，且能和其他定位元素做z-index层级协调 - 兼容性：IE9+ 都支持
top/left，transform在 IE9 需要-ms-transform
容易被忽略的 stacking context 问题
加了 position: relative 且设置了 z-index（哪怕只是 z-index: 0），就会创建新的 stacking context。这会影响内部子元素的层叠顺序，尤其嵌套多层时。
典型现象：弹窗里的按钮明明写了 z-index: 9999，却被外层遮罩盖住——可能就是中间某层 parent 无意中用 relative + z-index 切断了层级继承。
- 不必要就别设
z-index，哪怕只是 0；默认值auto不创建新 stacking context - 检查 Chrome DevTools 的 “Layers” 面板，能看到哪些节点已变成 stacking context
- 若必须用
relative偏移又怕层级混乱，优先考虑用margin替代，它不触发 stacking context
