position 取值决定 top/left 是否生效，仅 relative、absolute、fixed、sticky 有效；static 下被忽略。relative 相对自身偏移，absolute/fixed 相对最近非 static 祖先或视口，fixed 始终相对视口。
position 的取值决定了 top/left 能不能生效
直接写 top 或 left 是没用的，必须先设 position。常见取值中，只有 relative、absolute、fixed、sticky 会让 top/left 生效；static（默认值）下这两个属性被完全忽略。
实操建议：
-
relative：元素仍在文档流中占位，top/left是相对于自身原始位置偏移 -
absolute：脱离文档流，top/left相对于最近一个position不为static的祖先元素（没有就相对于初始包含块，通常是视口） -
fixed：也脱离文档流，但始终相对于视口定位，滚动不跟随 - 别忘了给父容器加
position: relative—— 这是控制absolute子元素定位范围最常用也最容易漏掉的一环
top/left 的数值单位和负值怎么用
top 和 left 支持多种单位：px、%、em、rem，甚至 calc()。百分比值的参照对象取决于 position 类型：
-
relative：百分比基于元素自身的宽高（top用 height，left用 width） -
absolute/fixed：百分比基于包含块的宽高（不是父元素的 padding box，而是 content box） - 负值完全合法：
top: -20px向上拉出，left: -100%可用于实现“滑入”动画的初始隐藏 - 注意：
top和bottom同时设置时，top优先级更高（除非元素高度固定且有冲突）
z-index 失效？大概率是 stacking context 搞的鬼
写了 z-index 却没效果，往往不是语法错，而是父级创建了新的层叠上下文（stacking context），把子元素“锁”在局部层级里。
立即学习“前端免费学习笔记（深入）”；
触发新 stacking context 的常见条件包括：
-
position不是static且z-index为具体数值（非auto） -
opacity小于 1 -
transform不是none -
filter不是none
后果是：子元素的 z-index 只在该 context 内部比较，无法越过父级去和外部元素争高低。查问题时，用浏览器开发者工具看元素 computed styles 中的 stacking context 提示，比盲目调 z-index: 9999 更有效。
移动端 fixed 定位常出现“闪动”或“错位”
在 iOS Safari 或部分安卓 WebView 中，position: fixed 配合 top/left 可能因缩放、键盘弹出、地址栏收起而错位，尤其在 viewport 设置不当时更明显。
缓解方案：
- 确保
<meta name="viewport">包含width=device-width, initial-scale=1，禁用user-scalable=no（否则某些系统会强制重排） - 避免对
fixed元素同时设置transform（如translateZ(0)）—— 它虽能开启硬件加速，但也可能触发新的 stacking context 或渲染异常 - 键盘弹出时，iOS 会重置视口高度，此时靠
vh计算的top值会失准；改用 JavaScript 监听resize并动态更新更可靠
真正稳定的定位逻辑，往往得在 CSS 和 JS 之间划好边界：CSS 负责声明式规则，JS 负责响应运行时变化。
