CSS 锚点定位实战：下拉菜单、气泡提示与自动翻转，全程不写 JS

但凡是浮层，位置计算都是躲不掉的工作。下拉菜单要贴着按钮底边，气泡提示要卡在图标正上方，用户滚到屏幕底部打开菜单时，还得自动翻到上面去——过去这些逻辑要么交给 Popper 这类库，要么自己拿 getBoundingClientRect() 加一堆 scroll、resize 监听硬算。麻烦的地方不在于算数字，而在于你还得盯着每一个可能让锚点位移的时机重新算一遍，漏掉一个就出鬼影。

锚点定位（Anchor Positioning）把这件事整个搬进了 CSS。给锚点起个名字，浮层声明“我跟着这个名字走”，浏览器自己就把位置算好了，锚点一动浮层跟着动，不需要重算。再配合 popover 属性，连开合逻辑都能从 JS 里拿掉。

我拿一个带下拉菜单和悬停提示的工具栏改造过一遍，删掉的定位代码大约九十行。下面是从零跑通的顺序，末尾是几个让我白忙活的坑。

核心只有三个属性名

这套东西用起来其实很轻，绕不开的就三个名字：

anchor-name，写在锚点元素上，给它起一个名字，值必须是双横线开头的自定义标识符，跟 CSS 变量一个规则。

position-anchor，写在浮层元素上，指向自己跟着哪个锚点。

anchor() 和 position-area，决定具体贴在哪个方位。前者返回一个长度，可以拿去填 top、left 这些属性；后者是个新属性，用九宫格的思路直接描述“放在锚点的哪一侧”。

先看最小可用的一对：

<button class="trigger">选项</button>
<div class="menu">......</div>

.trigger {
  anchor-name: --trigger;
}

.menu {
  position: absolute;
  position-anchor: --trigger;
  top: anchor(--trigger bottom);
  left: anchor(--trigger left);
}

这里 anchor(--trigger bottom) 的意思是“锚点元素底边那条线在页面上的纵坐标”，把它赋给 top，菜单就刚好贴着按钮下沿。左边对齐同理。两个属性写完，菜单位置就固定了，之后页面怎么滚、按钮怎么移动，菜单都会跟着——因为浏览器每次布局都会重新解这个表达式，不是缓存下来的一个死数字。

注意 position: absolute 这行不能少。锚点定位只对绝对定位或固定定位的元素生效，一个 position: static 的元素上写 anchor() 会被当成无效声明直接丢掉，浏览器控制台也不会报错，你只会觉得“怎么没反应”。

案例一：带自动翻转的下拉菜单

上面那段代码在页面中段很好用，但用户把页面滚到接近底部时打开菜单，菜单就会溢出到视口外面去。手工写翻转逻辑，就是判断菜单底部坐标有没有超过 window.innerHeight，超了就改成 bottom: 100%——一个 if，但要配一堆事件监听。

锚点定位里这一步叫 fallback（回退位置），写法是声明一串候选方案，浏览器按顺序挑第一个放得下的：

.menu {
  position: absolute;
  position-anchor: --trigger;
  position-area: bottom span-right;
  position-try-fallbacks: flip-block, flip-inline;
}

position-area: bottom span-right 这个语法值得拆开看。bottom 表示放在锚点下方，span-right 表示同时向右跨越锚点所在的列——组合起来就是“从按钮左下角开始，向下、向右铺开”，正好是下拉菜单最常见的位置。

flip-block 和 flip-inline 是两个内置关键字，分别表示沿块轴、行内轴翻转。flip-block 就是“放不下就上下对调”，flip-inline 是“左右对调”。写成逗号分隔的列表，浏览器从前到后试，第一个能完整显示的就被采用。

如果内置关键字不够用，还可以自己定义具体方案：

@position-try --above-left {
  position-area: top span-left;
  margin-bottom: 8px;
}

.menu {
  position-try-fallbacks: --above-left, flip-inline;
}

这个机制本质上是在做约束求解，而且是在浏览器的布局阶段完成的，不会触发 JS 那种“先渲染一帧错位、再在下一帧修正”的闪烁。

案例二：气泡提示与 Top Layer

气泡提示还有个额外麻烦：它得有最高的层叠优先级，不能被父元素的 overflow: hidden 裁掉，也不能被别的 z-index 盖住。以前要么把提示元素挂到 body 上用 position: fixed 手动算坐标，要么开一个高得离谱的 z-index 然后祈祷。

popover 属性天生解决这个问题——带 popover 的元素渲染在 Top Layer 里，自动脱离所有层叠上下文，也自动逃脱 overflow 裁剪。而且它能用纯 HTML 开合：

<button class="help" popovertarget="tip-1">?</button>
<div id="tip-1" popover class="tip">这项设置会影响导出格式</div>

.help {
  anchor-name: --help;
}

.tip {
  position-anchor: --help;
  position-area: top;
  margin: 0 0 8px 0;
  inset: auto;
  padding: 8px 12px;
  border-radius: 6px;
  background: #24292f;
  color: #fff;
  font-size: 14px;
}

这里有两行初看莫名其妙、删掉就出问题的声明。

第一行是 margin: 0 0 8px 0。margin 在锚点定位里有个特殊作用：它不再是简单的外扩，而是被当作浮层与锚点之间的间距来参与定位计算。想让气泡离开按钮 8px，就把外边距加在朝向按钮的那一侧。

第二行是 inset: auto。popover 元素的浏览器默认样式里带了 inset: 0 和 margin: auto，目的是让它在没有锚点时居中显示。这两条默认值会和锚点定位打架——我第一次写的时候气泡死活塞在视口正中间，加了 inset: auto 立刻归位。

还有一个挺贴心的属性，顺手写上：

.tip {
  position-visibility: anchors-visible;
}

anchors-visible 的意思是，锚点元素本身不可见（被隐藏、被滚出视口、或者 display: none）时，浮层跟着一起隐藏。不加这个，你可能会看到气泡孤零零地飘在页面上，而触发它的那个问号图标早就滚走了。

案例三：跟着滚动的容器内浮层

如果是把浮层放进一个可滚动容器里（比如一个纵向滚动的列表面板），情况稍微复杂一点：锚点和浮层必须处在同一个滚动上下文里，否则滚动时浮层会留在原地漂移。

这时候用 position-anchor 指名字是可以的，但更方便的是用 anchor-scope。把同一个 anchor-name 同时写在列表的多个行上，然后在外层容器上限制作用域：

.panel {
  overflow-y: auto;
  height: 360px;
  anchor-scope: --row;
}

.row {
  anchor-name: --row;
}

.row-tip {
  position: absolute;
  position-anchor: --row;
  position-area: inline-end;
  margin-left: 10px;
}

anchor-scope: --row 加在 .panel 上，等于告诉浏览器：“--row 这个名字在这个容器内部有效”，每个 .row-tip 就会自动匹配自己所在作用域里那个叫 --row 的锚点，而不是整个文档里第一个同名的元素。没有这个作用域限制，所有提示都会挤到第一行旁边去——我踩这个坑的时候排查了半天，一直以为是自己 position-area 写错了方向。

四个实际踩过的坑

名字必须以双横线开头。anchor-name: trigger 是无效的，必须写 --trigger。和自定义属性同一个命名规则，这点倒是没什么意外，但错误提示很不明显，容易以为属性没生效。

anchor() 只能用在外边距相关属性上。top、left、inset 系列、margin、width、height 都行，但你要是把它塞进 transform 或者 background-position，整条声明直接作废。anchor-size() 才是管尺寸的，返回值是长度，可以拿来让浮层和锚点等宽。

锚点被 display: none 后，定位表达式失效。如果浮层不是用 popover 而是靠 JS 切换类名来控制显示，锚点元素本身在隐藏状态下不参与布局，anchor() 算出来的就是 0px，浮层会出现在左上角。解决办法是让按钮始终留在布局里，用 visibility 或者 opacity 切可见性，而不是 display。

用 position-area 的时候不要再手动写 top 和 left。这两者会互相覆盖，具体谁赢取决于书写顺序和属性优先级，很难猜。二选一，我个人倾向用 position-area，语义清楚，改起来也不用同时动四个方向。

完整可跑的页面

把三个案例合起来，一个文件，不含任何脚本：

<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<style>
  body {
    margin: 0;
    min-height: 200vh;
    padding: 60vh 20px 20px;
    font-family: system-ui, sans-serif;
    background: #10131a;
    color: #d5dbe5;
  }
  .bar {
    display: flex;
    gap: 12px;
    padding: 12px;
    background: #1a1f29;
    border-radius: 10px;
    width: fit-content;
  }
  .btn {
    padding: 8px 14px;
    border: 1px solid #2c3542;
    background: #222a36;
    color: #d5dbe5;
    border-radius: 6px;
    cursor: pointer;
    font-size: 14px;
  }

  #b1 { anchor-name: --b1; }
  #b2 { anchor-name: --b2; }

  .menu {
    position: absolute;
    position-anchor: --b1;
    position-area: bottom span-right;
    position-try-fallbacks: flip-block, flip-inline;
    margin: 6px 0 0 0;
    inset: auto;
    padding: 6px;
    min-width: 160px;
    background: #1a1f29;
    border: 1px solid #2c3542;
    border-radius: 8px;
  }

  .tip {
    position-anchor: --b2;
    position-area: top;
    position-try-fallbacks: flip-block;
    position-visibility: anchors-visible;
    margin: 0 0 8px 0;
    inset: auto;
    padding: 6px 10px;
    border-radius: 6px;
    background: #3b2f6b;
    color: #fff;
    font-size: 13px;
    white-space: nowrap;
  }

  @supports not (position-anchor: --x) {
    .menu, .tip { position: fixed; top: 50%; left: 50%; }
  }
</style>
</head>
<body>
  <div class="bar">
    <button class="btn" id="b1" popovertarget="m1">更多操作</button>
    <button class="btn" id="b2" popovertarget="t1">?</button>
  </div>

  <div id="m1" popover class="menu">
    <div>重命名</div>
    <div>复制链接</div>
    <div>移到回收站</div>
  </div>

  <div id="t1" popover class="tip">这项设置会影响导出格式</div>
</body>
</html>

页面上下都留了很大空白，把窗口拉矮一点，点开“更多操作”，就能看到菜单自动翻到按钮上方——这个翻转过程不需要写任何判断。

写在最后的一点判断

锚点定位现在在 Chrome、Edge 和 Safari 上都已经可用，Firefox 也在推进。真实项目里我的做法是：功能位置用 @supports 判断，不支持的环境退回一个简单但可用的 CSS 定位（比如 position: fixed 居中），不追求降级体验完全一致。因为这部分本来就是装饰性增强，最怕的是为了兼容搭进去一堆 JS 反而回到起点。

适合用它的场景挺明确：菜单、提示、浮层标注、挂件徽标，都是“跟着某个元素走”的东西。不适合的也很明确：需要根据浮层实际尺寸反向调整锚点的情况，或者浮层要跨越 iframe、Shadow DOM 边界去对齐。这类需求目前还得靠 JS 库来兜，CSS 这边暂时没有对应的口子。