彻底吃透CSS position定位：五种取值与高频场景避坑指南

相信很多人都有过类似的经历：明明知道 position 有 relative、absolute、fixed、sticky 这几种取值，真到做页面时却不敢下手。想做一个右下角悬浮消息球，写了个 fixed，结果滚动页面时它纹丝不动；想做吸顶导航，用了 sticky，却怎么都不触发；想做弹窗覆盖层，absolute 定位又跑到整个页面的最底部去了。问题出在哪儿？多半不是语法不会背，而是没有想清楚定位的参考系和占据规则。

这篇文章是“前端 CSS 精讲”系列第 6 篇，我们来把 position 彻底吃透，重点围绕三个高频场景展开：悬浮元素、吸顶导航、覆盖层弹窗。适合正在学 CSS 布局、或者已经能写页面但经常被定位问题卡住的前端学习者。我会尽量用“人话”讲原理，再给出可以直接抄的代码示例，最后盘点我实际踩过的坑。放心，这篇看完你至少能解决 80% 的定位问题。

1. 为什么 position 学了就忘：先建立“定位上下文”心智模型

1.1 普通文档流是默认坐标系

在没有给元素设置任何 position 之前，所有块级元素从上往下排，行内元素从左往右排，这就是普通流。普通流是浏览器默认的“排版流水线”，绝大多数页面内容应该留在普通流里，因为它足够稳：内容有多少就站多少地方，页面自然可以往下滚动。

一旦你给元素设置了 position，等于告诉浏览器：这个盒子不打算按默认规则排队了，我要单独说明它的位置。这里的重点不是“位置在哪”，而是“按哪套规则来判定位置”。很多时候我们只写了 position: absolute 和 left: 10px，却忽略了它到底相对于谁，于是元素出现在莫名其妙的地方。

我在教学时经常强调一句话：position 本身不说位置，它只决定“用哪把尺子量”，真正告诉浏览器盒子放在哪儿的是后面的 top/right/bottom/left，以及背后那套参考坐标系。先把这个概念理顺，后面的代码才不会写得一头雾水。

1.2 “相对于谁”是定位的第一问题

给一个元素设置了定位属性之后，首先要回答的问题就是：它是相对于父元素？还是相对于浏览器窗口？还是相对于自己原本的位置？不同类型的 position 会把“测量起点”指向不同的人。

比如 absolute 的测量起点，是最近的“定位祖先”。所谓的定位祖先，是指任意一个 position 不为 static 的元素。也就是说，如果某个祖先元素是 relative、absolute、fixed 或 sticky，它就会成为后代 absolute 元素的容器参考。如果往上翻了好久都找不到一个定位祖先，最终会以整个页面根元素作为参考。

而 fixed 的测量起点通常是视口（也就是你眼睛看到的窗口区域），所以滚动页面时它会像贴在了屏幕上一样。稍后我们还会聊到 fixed 被“篡改”参考系的情况，那是一个容易翻车的高级坑。

1.3 “占不占位置”比“怎么偏移”更重要

观察一个元素是否脱离普通流，比记一个 CSS 属性的语义更重要。relative 很有意思，它虽然可以把元素从原位置挪走，但原来的“坑位”依然保留，后面的兄弟元素不会顶上来。而 absolute 和 fixed 使用之后，该元素就不再参与普通流布局，原来的坑位会消失，后面元素会自然补位。

这个差异在处理“覆盖层”时非常核心。覆盖层通常希望它不占任何空间，又从底部浮上来盖住整个页面，所以大多使用 fixed 或 absolute。相对的，吸顶导航在滚动前本来就在页面流里占位置，滚动到顶部时才“吸”住，这种场景用 sticky 比用 fixed 更顺手，因为不用手动用 JS 去计算占位高度。

为方便对比，先放一张最常用的概览表，后续每个值我都会展开说明：

2. position 五种取值逐个攻破：static、relative、absolute、fixed、sticky

2.1 static：默认值，但很多人不知道它存在的意义

static 是 position 的默认值，我们平时不写 position 时，元素就是 static。它的作用很简单：元素按普通文档流排列，top/right/bottom/left 和 z-index 全部无效。

你可能会觉得这个没得讲，但它在实际开发里有一个用处：你想让某段代码不去依赖继承来的定位规则，主动把 position 重置为 static 就能回到普通流。比如某些组件库的样式可能会给通用类加上 position: relative，你在使用时要让它“恢复身份”，直接写 position: static 就可以。

另一个常见场景是排查布局问题：当某个绝对定位元素始终定位准确，但页面结构临时变化，你想快速验证它是不是被某个祖先进影响时，把祖先进几个疑似角色的 position 改成 static 看现象，效率会很高。不要小看这个值，做实验时它是很好的对照参照。

2.2 relative：自身偏移，保留占位，还是定位锚点

relative 最直觉的理解是“相对自己原来的位置做偏移”。它不脱离文档流，就算你写了 top: 20px; left: 20px;，元素只是视觉上移动了，原位置依然占着，后续兄弟元素位置完全不受影响。

因为它不脱流，我经常拿来处理一些很小的位置微调。比如给一个搜索框里的放大镜图标做个 1px 对齐，用 relative + top: 1px 就解决，没必要为了几像素给元素加 margin 把周边布局都带乱。它像是你站在固定站位上往旁边侧身，别人看到你移了位置，但你的“工位”还在那儿。

relative 另一个价值是当 absolute 的定位锚点。我们写组件时，如果希望一个关闭按钮能相对整个弹窗面板定位，一般会把弹窗面板设置成 position: relative，这样按钮无论放在面板内部哪个角落，都能用 absolute 相对面板定位，即使面板内部的 DOM 结构变化，按钮也始终跟着面板走。

2.3 absolute：脱离文档流，寻找最近的定位祖先

absolute 一旦生效，元素会脱离文档流，它会忽略自己在普通流里应该占据的空间，后面的元素像它不存在一样往上靠。同时它的定位参考是“最近的定位祖先”，我在 1.2 已经解释过，通常我们会给父容器设置 position: relative，让它成为子元素的锚点。

这里需要特别提醒：如果你只给子元素写了 position: absolute，但父元素没有定位属性，它不会“聪明地”去找父元素，而是继续一级一级往上找。最终找不到定位祖先时，会相对根元素，也就是整张页面定位。这时如果你设了 left: 0，它可能出现在页面最左，而不是父容器左边缘附近。很多人都因为忘记给父元素加 relative，导致弹层跑到页面左上角。

absolute 配合 top/right/bottom/left 使用时，可以精确控制相对边缘的距离。比如“按钮右上角的删除角标”可以写成：

css复制.badge {
  position: absolute;
  top: -6px;
  right: -6px;
}

只要它的父容器设置了 position: relative，无论按钮在那个容器里怎么换位置，角标都能牢牢贴着右上角。下面我会在实战里展示更完整的覆盖层写法。

2.4 fixed：相对视口固定，但 transform 会把参考系带跑

fixed 一般理解是“钉在浏览器窗口上，滚动也不动”。它是实现全局悬浮按钮、侧边客服、页面底部操作栏的最直接方案。比如返回顶部按钮写到页面右下角，只需要：

css复制.return-top {
  position: fixed;
  right: 20px;
  bottom: 40px;
}

不管用户滚动到哪里，这个按钮始终显示在视口右下角。需要注意的是，fixed 不占文档流空间，所以不需要担心它会顶开其他布局。

但现代浏览器有一个非常隐蔽的规则：如果 fixed 元素的某个祖先进设置了 transform、perspective、filter、will-change、contain 等属性，那么该祖先不再只是普通祖先，它会变成一个“包含块”，fixed 元素就会从“相对视口固定”变成“相对那个祖先固定”。 我遇到过真实案例：一个组件内部为了入场动画在父容器写了 transform: translateY(0)，结果里面原本希望浮在页面右下角的消息提示，页面往下滚时跟着组件一起消失。排查大半天才发现是这行 transform 惹的祸。这条经验值得重点划线，后面修复章节也会再次提到。

2.5 sticky：原生吸顶方案，但生效条件比想象严格

position: sticky 是 CSS 后来加入的吸顶方案，它不像 fixed 那样从头到尾钉在视口上，而是先按普通文档流排列，等滚动到某个阈值时才“暂时吸住”。因为它保留了原来的位置，滚动开始前不会遮盖后面的内容，所以做吸顶导航特别自然。

一个基础的吸顶导航写法：

css复制.site-nav {
  position: sticky;
  top: 0;
}

当 .site-nav 到达视口顶部时，它就会停在顶部不动，直到它的父容器滚出视野。这个效果用 fixed 实现其实非常麻烦：需要监听滚动、计算导航栏原始位置，还得手动补一个占位元素，否则标题会遮挡内容。而 sticky 原生解决，且不改变布局。

同样，sticky 不是设置完就必然生效。生效条件包括：必须设置 top（或其他阈值，不能为空）、父容器高度要大于这个元素本身、父容器不能有 overflow: hidden 切断吸附、元素本身也不能被某个 overflow 容器包住导致滚动能力失效。这些条件我全部踩过，之后的故障排查章节会再列一份自查清单。

3. 偏移量、z-index 与居中：定位之后的第二道关卡

3.1 偏移量：top/right/bottom/left 到底按什么规则计算

设置了 position 后，我们就可以用 top/right/bottom/left 四个方向值来描述元素的位置。其中 top 和 bottom 是垂直方向的偏移，left 和 right 是水平方向偏移。它们可以设置具体像素、百分比，或者 auto。

当一个定位元素同时设置了 top 和 bottom 时，垂直方向会被拉伸，直到同时满足这两个边界；水平方向同理，同时设置 left 和 right，如果没设宽度，元素就会被拉宽到左右两边界之间。这也是覆盖层背景常用的技巧：

css复制.overlay {
  position: fixed;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
}

这一句等于让遮罩层铺满整个视口。现在有一个更简洁的 inset: 0，它等价于四个方向都为 0，写起来更快。兼容性方面现代浏览器都没问题，如果你维护的旧项目要支持很老的浏览器，建议还是老老实实写四行。

百分比计算也有讲究：left: 50% 是相对包含块宽度的 50%，top: 50% 是相对包含块高度的 50%，而不是相对元素自身。所以在做“绝对定位居中”时不加其他处理，元素左上角会落在正中，而不是正中心。解决办法是再使用 transform: translate(-50%, -50%)，把元素自己向左上平移自身一半尺寸，但标准做法也可以借助 flex，等下我会给完整案例。

3.2 z-index：只有“从同一层叠上下文出发”才不会失控

很多学习者把 z-index 理解成“越大越靠前”，这句话大方向上没错，但忽略了它会受层叠上下文的影响。层叠上下文有点像一个“组内排序规则”：一个元素创建了自己的层叠上下文后，它内部的子元素再设 z-index，只能在它这个小组内部比较大小，不能跟小组外的元素直接比大小。

能创建层叠上下文的情况很多，常见的有：定位元素且 z-index 不为 auto、transform 不为 none、opacity 小于 1、filter 不为 none 等。所以实际开发中会见到这种诡异问题：给弹窗设了 z-index: 9999，依然被另一个看起来 z-index 很小的浮层遮住，原因往往是前一个弹窗被一个祖先元素包住，祖先元素创建了层叠上下文，把它的整体层级压低了。

解决思路不是盲目调大一个巨大的数字，而是检查弹窗和另一个浮层是否处于同一个层叠上下文。把它们放到同一层级，或调整祖先的层叠关系，问题往往迎刃而解。另外建议项目里定义一套层级规范，比如把 z-index 分为几个固定档位：背景遮罩 100、弹窗 200、提示气泡 300、全局 loading 400，避免大家随手写 9999 导致后期难以维护。

3.3 定位元素怎么居中：百分比偏移加 transform 的老方法

绝对定位元素居中是一个高频问题。比如关闭按钮、loading 动画、弹窗内容区，都要出现在容器正中央。老式做法是：

css复制.center {
  position: absolute;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
}

原理很好理解：left: 50% 让元素左上角到容器横向中点，top: 50% 让元素左上角到容器纵向中点，transform: translate(-50%, -50%) 再把元素向自身宽高的一半偏移回去。这种方式不依赖元素自身尺寸，内容多宽多高都能保持居中，兼容性也不错。

但是要注意 transform 会创建包含块和层叠上下文，如果这个居中元素内部还有 fixed 后代，就可能出现“fixed 不固定在视口”的连带问题。所以现代项目里我更推荐用 flex 布局来居中：把外层遮罩容器设置成 flex + align-items/justify-content，里面的弹窗内容自然居中，根本不需要对内容本身做绝对定位计算。不过二者都有适用场景，理解背后原理才能取舍。

4. 实操：悬浮按钮、吸顶导航、覆盖层弹窗怎么落地

4.1 热点场景一：右下角悬浮按钮（返回顶部 / 消息球）

悬浮按钮的本质就是让元素脱离普通流，然后相对视口固定在一个位置。最常见的右下角返回顶部按钮代码可以这样写：

css复制.return-top {
  position: fixed;
  right: 20px;
  bottom: 40px;
  width: 48px;
  height: 48px;
  border-radius: 50%;
  background-color: #333;
  color: #fff;
  z-index: 99;
  cursor: pointer;
}

为什么用 fixed 而不是 absolute？因为返回顶部按钮希望无论页面滚到多深，它都出现在屏幕右下角；如果你用 absolute 相对某个容器定位，它只会出现在那个容器内的固定位置，页面一滚它就会跟着容器走，不能一直“悬浮”在窗口上。

如果你的项目需要适配 iPhone 底部小黑条，建议把 bottom 写成安全区自适应：

css复制.return-top {
  bottom: calc(20px + env(safe-area-inset-bottom, 0px));
}

我第一次适配全面屏手机时，直接把按钮写死在 bottom: 20px，结果在 iPhone 上按钮顶着底部横条，视觉非常拥挤。后来统一用安全区变量解决，顺带也兼顾了安卓虚拟按键的情况。给浮动按钮加 z-index 也是有必要的，否则页面正文里的定位元素很可能在滚动时和按钮叠在一起。

4.2 热点场景二：吸顶导航栏，用 sticky 比固定定位更省心

一个常见的吸顶结构是：顶部 Hero 大图、导航栏、正文内容。希望在 Hero 区域滚出屏幕后，导航栏始终停在窗口顶部。HTML 结构类似：

html复制<div class="page">
  <section class="hero">首屏大图</section>
  <header class="page-nav">导航</header>
  <main class="content">正文内容</main>
</div>

CSS 只需要给导航栏设置：

css复制.page-nav {
  position: sticky;
  top: 0;
  z-index: 50;
}

这时导航栏在未达到视口顶部前，会老老实实待在 Hero 下方；一旦滚动到 top: 0，它就会像吸附一样停在顶部，等 .page 容器完全滚出后，它也会跟着离开。你会发现它始终参与普通文档流，所以不需要像 fixed 那样额外加一个占位 div 去抵消高度。

需要注意父容器 .page 的高度要足够大，否则导航栏一吸住就到底了，看不到效果。如果 sticky 没有生效，你可以从三个方向排查：有没有给顶部阈值（比如 top: 0）；父容器高度是否大于该元素至少一点；父子容器是否存在 overflow: hidden 剪裁。很多时候导航栏能滚动，但因为其中一个祖先设置了 overflow-x: hidden，粘性定位就被悄悄破坏了，这个问题很隐蔽，我在下面的故障排查里详细讲。

4.3 热点场景三：覆盖层弹窗背景、内容层与关闭按钮

覆盖层一般由两层组成：最底下的半透明黑色遮罩，以及中间的弹窗内容面板。遮罩的作用是挡住页面并营造视觉焦点，所以它必须铺满整个可视区且不参与文档流。推荐结构：

html复制<div class="modal-overlay">
  <div class="modal-panel" role="dialog" aria-modal="true">
    <h2>删除确认</h2>
    <p>确定要删除这条记录吗？</p>
    <button class="modal-close" type="button">关闭</button>
  </div>
</div>

基础样式：

css复制.modal-overlay {
  position: fixed;
  inset: 0;
  background: rgba(0, 0, 0, 0.55);
  display: flex;
  align-items: center;
  justify-content: center;
  z-index: 100;
}

.modal-panel {
  position: relative;
  min-width: 320px;
  padding: 24px;
  background: #fff;
  border-radius: 8px;
  box-shadow: 0 20px 60px rgba(0, 0, 0, 0.2);
}

.modal-close {
  position: absolute;
  top: 12px;
  right: 12px;
  border: none;
  background: transparent;
  cursor: pointer;
}

这里的 .modal-overlay 没有脱离整个 html 结构，但因为它是全屏 fixed 定位，用户视觉上看到的只有半透明遮罩和弹窗。.modal-panel 设置 position: relative 的原因是让关闭按钮可以用 position: absolute 相对弹窗面板定位，不受内部其他内容布局影响。

同时要注意滚动穿透问题。遮罩出现后，用户滚轮或手机滑动时，底层页面经常会跟着滚动，体验比较糟糕。最简单的处理是给 body 加一个类：

css复制body.modal-open {
  overflow: hidden;
}

打开弹窗时加上，关闭弹窗时移除。但如果你的项目里弹窗很频繁，而且页面又比较长，可以用 JS 记录当前滚动位置后再锁 body，关闭时恢复。这里有个小坑：桌面端滚动条会在锁住的瞬间消失，页面内容宽度会变化，导致横向抖动。解决思路是在锁 body 的同时补偿一个等宽的 padding-right，具体宽度可以动态测量文档宽度和视口宽度之差。

5. 定位失效排查：这些坑我基本都踩过

5.1 症状：sticky 根本没“吸”住

先说一个真实例子：我给一个分类 tabs 设置了 position: sticky; top: 0;，在 Chrome 里起初一切正常，后来把它包进一个有横向滚动的轮播容器后就不生效了。原因是祖先元素使用了 overflow-x: auto，从而创建了新的滚动容器，sticky 不再相对原来的页面滚动容器工作，或者吸顶空间被那层滚动容器截断。

如果你不幸遇到了 sticky 不生效，按以下顺序自查：

• 是否设置了 top / left / right / bottom 至少一个阈值？只写 position: sticky 不设 top:0 是不会吸的。
• 父容器高度是否足够？如果父容器高度和 sticky 元素一样，元素一滚动就出走，完全没有“吸住旅程”。
• 祖先或父元素有没有 overflow: hidden / scroll / auto？如果有，尽量去掉；若只是为了解决横向溢出，建议把样式从 overflow 改成 overflow-x: clip（支持现代浏览器），可以避免影响 sticky。
• 是否把 position: sticky 和 position: fixed 搞混了？sticky 生效是一个过程，它最初在普通流里，只有滚动到阈值后才会吸顶。

还有一点，sticky 的“吸住范围”被限制在父元素内，父元素滚出视口时，它也会跟着父元素一起滚出。要实现“不管父元素在哪儿，导航始终吸在窗口顶部”，那就该用 fixed + 占位或其他方案，比如 JS 动态定位。

5.2 症状：fixed 元素不固定在窗口，反而跟着某个祖先滚动

前面讲过，当祖先存在 transform、filter、perspective、will-change: transform、contain: layout 等属性时，浏览器会把该祖先当作 fixed 元素的包含块。于是明明写了 position: fixed 的返回顶部按钮，却跟着一个有入场动画的容器滚出了页面。

排查思路很简单：从那个 fixed 元素往 DOM 树上层找，看有没有 transform / filter 的祖先。一旦发现，可以分情况处理：如果动画是阶段性的，等动画结束后通过 JS 把 transform 属性移除；如果父容器只是为了做浮层提升，可以改用其他方式创建层叠上下文，比如把样式移到 position: fixed 的元素本身上或把需要动画的节点放到别的层级。

我建议在做 position: fixed 之前，花几分钟看一下浏览器开发者工具里的 Computed 面板，确认父链路上没有这些“意外制造包含块”的属性。出现问题时不要急着调 z-index，先确认参考坐标系对不对。这个问题和 z-index 无关，调再大也没用。

5.3 症状：absolute 定位到了页面边缘，而不是父元素旁边

这种情况最常发生在刚刚入门时：子元素写了 position: absolute，想把图标放到按钮右上角，但最终却跑到了页面边缘。原因是父元素没有定位属性，子元素找不到定位祖先，只能一路向上定位到根元素。

修改方式很简单，给父容器加上：

css复制.parent {
  position: relative;
}

同时注意，如果父元素本身就是一个 absolute 定位元素，它也能作为内部覆盖层的定位容器，不一定非得用 relative。重要的是“父级 position 不为 static”。调试时也可以在浏览器 Elements 面板里选中这个 absolute 元素，看它顶部显示的计算包含块尺寸，浏览器会标出是哪个元素在约束它。

如果项目里很多地方都需要给元素加定位锚点，我会建议提前定一个通用工具类 .pos-rel { position: relative; }，在模板里按需使用。不过也要注意不要到处给不需要的元素加，类名容易混乱，更推荐在具体场景里语义化命名。

5.4 症状：弹窗遮罩明明设置了 fixed，却只盖住了一半屏幕

出现这个现象，十有八九是 .modal-overlay 被某个有 transform 的祖先包裹，导致它的 fixed 参考系从视口变成了该祖先。想象一下祖先是一个高度只有 500px 的卡片，遮罩里的 inset: 0 会去覆盖整个 500px 卡片区域，而不是浏览器窗口，于是你看到遮罩只盖住了页面三分之一高度。

解决方式跟 5.2 的方法很像：找到并移除祖先的 transform / filter 等属性，或者把弹窗外层移动到一个没有 transform 的 DOM 层级。如果动画组件类库里封装了 transform 效果，可以考虑给它加一个专门的“portal”容器，把弹窗挂到 body 直接子节点再渲染，这样能彻底绕开中间的包含块干扰。这也是现在很多组件库内部会用 createPortal 渲染弹窗的原因之一。

大型项目里还有一种情况是弹窗覆盖层套弹窗，比如弹窗 A 内部又弹一个确认框 B。B 不能放在 A 的 DOM 内部，否则 z-index 比较会受到 A 这个层叠上下文的限制。通常我会把确认框 B 通过 portal 渲染到顶层，确保它和遮罩 A 在同一个层叠上下文中，再用统一层级规则控制谁在最上面。

5.5 症状：两个元素 z-index 相差很大，低的却盖住了高的

z-index: 999 的元素被 z-index: 10 的元素盖住时，不要先质疑浏览器，应优先看两者的层叠上下文归属。当一个定位元素的祖先创建了层叠上下文，这个元素的 z-index 数值只能在祖先内部发挥作用；对外，它的整体层级是由祖先的 z-index 决定的。

举个例子：滚动容器 A 设置了 z-index: 1，里面有一个 z-index: 999 的子浮层；另一个普通容器 B 设置了 position: fixed; z-index: 100。但因为 A 作为整体层级很低，A 内部子浮层再高也超不过 B。解决办法有两个：把需要高层的浮层移到 A 容器之外，或把 A 的层叠上下文层级调高。别只盯着子元素调 z-index，那是在错误的坐标系里拧螺丝。

另外，position: static 元素上的 z-index 是无效的，除非该元素属于 flex 或 grid item，这样它也可以参与层叠排序。如果你遇到某个元素 z-index 怎么设置都不见效果，先检查它有没有定位属性，或者它是不是 flex / grid 的直接子项。

6. 一点建议和一小组适合动手验证的练习

6.1 建议先用手写练习脱离“背属性”的状态

前面聊了这么多，如果你只是“读过”而没有动手敲，大约下周就会忘掉。我见过很多学习者在看定位属性时觉得简单，一旦从静态页面转到真实项目，就会因为“画布坐标系不对”“占位没补”“层级没理顺”而反复卡壳。定位本事不是死记几个属性值，而是在脑海里维护一个心智模型：元素是否在普通流里？参考系是哪个？层级由谁决定？

我建议先做一个小练习：不用任何框架，写一个简单的页面，分成顶部 Hero、导航栏、正文长内容、右下角返回顶部按钮、点击按钮弹出覆盖层。观察滚动过程中导航栏什么时候吸顶、按钮是否一直固定、弹窗激活后 body 滚动是否被锁定，再尝试给按钮用一个 transform 动画容器包裹，看看 fixed 参考系会发生什么变化。这个练习只要完整做一遍，很多点就能连成一条线。

6.2 一个极简的检查清单，写代码前过一遍

在我日常写定位相关组件时，心里基本会默念一套检查清单，整理出来供你参考：

• 这个元素需要留在文档流里吗？如果希望它不影响兄弟元素布局，选 absolute 或 fixed；如果既要参与布局又要微调，选 relative。
• 它会随着页面滚动一直存在吗？是的用 fixed；如果是正常流动，到达某个位置后吸住，用 sticky。
• 它的定位参考是谁？如果是 absolute 组件内部定位，确保最近的定位祖先是期望容器，否则主动给父级加 relative。
• 是否存在设置了 transform/filter 的祖先？带着这个怀疑去 DevTools 里查清楚，避免 fixed 被带偏。
• 层级出现冲突时，先问“这俩元素在同一个层叠上下文吗”，别只改 z-index。
• 吸顶不生效时，检查祖先有没有 overflow 干扰，以及父容器高度够不够。

这套清单不一定覆盖所有极端场景，但足够帮你解决日常八成以上的定位问题。等你以后写组件库、写复杂后台页面时，会发现这些其实都是基础能力。最初我花了不少时间研究为什么 fixed 会变成 relative 的表现，也曾在多个弹窗相互层叠时被折磨到凌晨，后来把这些失败经验整理成一份“定位故障排查表”，再遇到问题就快多了。

如果现在有人问我，选 fixed 还是 sticky 做吸顶，我会告诉他：先看这个元素本身在不在文档流里。如果它天然出现在页面流里，吸顶后又不想让后续内容被挡住，优先 sticky；如果它属于一个完全不占位、纯粹浮在窗口边缘的层，用 fixed 更合适。定位没有“万能解”，只有搞清楚坐标系和占位规则之后，你才能在每个具体场景里做出正确选择。