CSS Anchor Positioning 适合解决哪些浮层布局问题？

简答

anchor-name 给锚点命名，position-anchor 让绝对或固定定位的浮层引用它，浮层不必是锚点的后代。
精确贴边用 anchor() 引用锚点的某条边；列表里同名锚点要用 anchor-scope 限定，否则会找到最后一个同名锚点。
放不下时用 position-try 等回退位置，不支持的浏览器用 @supports 降级。
它只负责几何关系，打开关闭、Escape、焦点和 ARIA 状态仍要自己实现。

工具提示、下拉菜单和上下文菜单通常要贴着一个按钮，同时不能跑出视口。传统做法是 JavaScript 读取按钮的 getBoundingClientRect()，计算 top/left，再监听滚动和窗口变化；这会增加测量、重排和生命周期管理成本。

CSS Anchor Positioning 让一个元素声明为锚点，另一个绝对或固定定位元素引用它的几何位置。它能减少一部分命令式测量，但仍是较新的 CSS 能力，语法、浏览器覆盖和复杂滚动场景要按目标环境验证。

锚点定义的是关系，不是 DOM 父子结构

HTML

<button class="help-button" type="button" aria-describedby="help-popover">
  帮助
</button>
<div id="help-popover" class="help-popover" role="tooltip">
  这里是说明文字。
</div>

CSS

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

.help-popover {
  position: fixed;
  position-anchor: --help-anchor;
  position-area: block-end span-inline-end;
  margin-block-start: 0.5rem;
}

anchor-name 给元素命名，position-anchor 让浮层引用它；浮层不必是按钮的后代。需要精确贴边时，用 anchor() 函数引用锚点的某条边：

CSS

.tooltip {
  position: absolute;
  position-anchor: --save-button;
  top: anchor(bottom);
  left: anchor(center);
  translate: -50% 0.5rem;
}

/* 列表里每一项都叫 --row-action 时，限定名称只在本项内查找 */
.row {
  anchor-scope: --row-action;
}

列表重复渲染同名锚点时，不加 anchor-scope 的话，所有浮层都会找到最后一个同名锚点。各浏览器的支持版本以 MDN 兼容表为准，上线前用 @supports (anchor-name: --a) 提供回退。

如果页面存在多个同名锚点，必须明确哪个元素会被引用，不能让组件实例依赖全局名称碰巧解析正确。组件销毁和重复渲染时也要保持名称作用域清楚，避免一个浮层漂到另一个实例的按钮旁边。

回退位置要表达“放不下怎么办”

浮层可能贴近视口边缘、滚动容器或键盘。只指定一个理想位置不能保证它永远可见；应定义备用位置或使用 position-try 等相应机制，并为不支持的浏览器提供降级：

CSS

@supports (anchor-name: --help-anchor) {
  .help-popover {
    position: fixed;
    position-anchor: --help-anchor;
    position-area: block-end;
    position-try-fallbacks: flip-block, flip-inline;
  }
}

@supports not (anchor-name: --help-anchor) {
  .help-popover {
    position: absolute;
  }
}

示例只表达渐进增强思路。position: absolute 的降级仍需要合适的定位容器和可能的 JavaScript 计算，不能因为有一条 fallback 规则就保证弹层不会出界。

浮层的定位上下文、position: fixed、transform 祖先、滚动容器和 top layer 会影响最终结果。一个视觉上贴着按钮的元素，可能在另一个裁剪或层叠上下文中被截断；Anchor Positioning 不会自动取消所有 overflow 和 z-index 限制。

CSS 定位不能替代交互状态

Anchor Positioning 只负责几何关系，不会自动实现打开、关闭、Escape、焦点移动、点击外部关闭或读屏语义。工具提示、菜单和对话框是不同模式，不能因为它们都“浮在按钮旁边”就使用相同的 ARIA 和焦点策略。

如果浮层由按钮控制，应同步 aria-expanded、aria-controls 或 aria-describedby；真正需要操作的菜单通常要管理焦点，不能只用 :hover 显示。触摸、键盘、缩放和移动端虚拟键盘也可能改变可用空间。

与 JavaScript 测量相比的取舍

CSS Anchor Positioning 适合锚点和浮层关系主要由布局决定的场景，能让浏览器参与回退和滚动更新，减少手写监听和几何同步。JavaScript 仍适合复杂碰撞算法、跨窗口坐标、拖拽和需要读取业务状态的定位。

不应把 JavaScript 全部删除后再发现业务需要知道浮层实际位置。必要时仍可以用 ResizeObserver、IntersectionObserver 或 getBoundingClientRect() 做业务判断，但要避免每次滚动事件都强制布局。

兼容性降级要保持功能可用：不支持新属性时，菜单仍应能打开、内容仍应可读、键盘仍能操作。不能因为追求漂亮的自动翻转就让旧浏览器中的按钮没有任何可发现的替代入口。

验收应覆盖锚点靠近四个边缘、滚动容器、缩放、长文本、多实例、动态插入、键盘焦点、读屏器、触摸和不支持该 API 的浏览器。布局 API 通过只证明位置关系成立，不证明完整浮层交互已经可用。