定位元素的 offsetParent 是最近的非 static 定位祖先元素；若无则为 body 或 html，需通过 DevTools 的 Computed 面板确认真实 offsetParent，排查 DOM 结构合法性、盒模型挤压及层叠上下文干扰。
定位元素的 offsetParent 是谁？
绝对定位元素不以视觉上的父容器为锚点，而是找最近的非 static 定位祖先——这个祖先就是它的 offsetParent。很多“定位失效”其实是锚点错了。
打开 DevTools → Elements 面板 → 选中该元素 → 看右侧面板「Computed」里 position: absolute 下方的 offsetParent 是哪个节点。如果显示为 body 或 html，说明中间所有父级都没生效，不是 CSS 写漏了，是 DOM 结构或定位上下文被浏览器绕过了。
- 嵌套表格中，
<td>默认不是定位上下文，想让它当锚点，必须显式加position: relative - Flex 或 Grid 容器里的子元素，即使父级设了
position: relative，只要没触发层叠上下文（比如没设z-index），仍可能被跳过 - 语义标签如
<header>在 IE8–11 中默认是inline，不会创建 BFC，也不构成定位上下文
HTML 嵌套结构是否被浏览器重写？
浏览器对非法嵌套会自动纠错，但纠错结果不可控——你写的结构和实际渲染的 DOM 往往不一致，导致定位锚点“凭空消失”。这不是 CSS 问题，是 HTML 语法错误。
在 Elements 面板中逐级展开，确认你要作为定位父容器的那个 <div> 确实包裹着目标元素。常见陷阱：
立即学习“前端免费学习笔记（深入）”；
-
<img>、<input>等 void 元素误写成<img></img>，浏览器会当成两个标签处理，后续所有嵌套偏移一格 -
<p>里嵌<div>：浏览器直接拆开，变成<p></p><div></div><p></p></li> <li>交叉闭合：<code><div><p>文字</div></p>
→ 实际解析为<div><p>文字</p></div>，但中间<p>被提前截断
用 W3C Validator（validator.w3.org）粘贴片段，重点看 Element div not allowed as child of element span 这类报错。
父容器盒模型是否挤压了定位空间？
即使锚点正确，padding、line-height、vertical-align 和 overflow: hidden 也会让 absolute 元素“出不来”或“偏一点”。尤其在表单控件旁放图标、日期选择器触发器时特别明显。
- 给定位父容器加
box-sizing: border-box，避免padding缩窄内容区 - 禁用
overflow: hidden——它会裁掉absolute元素超出部分，而很多 UI 框架默认加了这个 - 避免在父级设
height或max-height，不同浏览器对absolute元素基线计算不一致，导致上下偏移 - 对
<input type="date">统一设vertical-align: middle，防止与文字基线错位
z-index 是否被层叠上下文锁死？
设了 z-index: 9999 还被盖住？大概率是父容器提前创建了层叠上下文，把子元素“关进小房间”了。此时它的 z-index 只在房间里有效，出不去。
检查所有祖先节点是否触发了层叠上下文——常见触发条件：
-
position非static且z-index不为auto -
opacity小于 1 -
transform非none（包括translateZ(0)） -
filter非none
Chrome DevTools 的 Computed 面板会明确标出 “This element establishes a stacking context”。临时删掉可疑样式验证；若必须保留，考虑把 transform 或 opacity 上移到更高层级容器，而非包裹目标元素的直接父级。
真正难排查的，往往不是某一行 CSS 写错了，而是 DOM 结构在浏览器里已经不是你写的那样了——得先看清真实结构，再谈定位。
