配了三年 Floating UI，今天发现 Interop 2026 把它的生存空间彻底灭了——CSS Anchor Positioning 三引擎全部上线，这件事把工具链的账全变了

CSS Anchor Positioning 早就有了，但五年了团队还在装 Floating UI——这件事今天被 Interop 2026 彻底翻了

配了三年弹层定位，每次接新项目第一件事就是 npm install @floating-ui/dom。tooltip 要装、dropdown 要装，popover 要装，理由永远是「浏览器不支持」。2026 年了，Chrome/Firefox/Safari 三大家全部上线，Interop 2026 还专门把它列为核心攻坚目标——但大多数团队的根本没动。根子不在兼容性，在认知惯性。

这篇文章不是又一篇「Anchor Positioning 怎么用」。那玩意儿官方文档写得比我的好。这篇要算的是另一笔账：你的团队什么时候应该认真考虑把那 12KB 的依赖删了，以及 Interop 2026 到底改变了什么。

先说结论：2026 年第三季度，CSS Anchor Positioning 的跨浏览器互操作问题已经被 Interop 2026 基本解决了。真正阻碍你删掉 Floating UI 的，不是技术，是流程。

五年了，浏览器其实早就能做这件事

CSS Anchor Positioning 的规范在 2023 年就开始草案，到 2025 年 Chrome 和 Safari 已经上线了大部分能力。Firefox 在 2026 年 1 月跟进，Firefox 147 正式把 Anchor Positioning 和 Navigation API 一起推进了 Baseline Newly Available。2026 年 2 月 Interop 2026 把它列为年度重点，Apple / Google / Microsoft / Mozilla / Igalia 五方共同承诺：同一套测试标准，同一个通过门槛，跨引擎行为一致。

这件事的重量级被严重低估了。

之前 Anchor Positioning 在 Chrome 能用，在 Safari 部分能用，在 Firefox 跑不通——等于没戏唱。Interop 2026 把它拉到了同一张考卷上：四家引擎都得在同一个 Web Platform Tests 套件里达到同一个分数线。这才是真正的「可用」，不是某一家发了就当全行业发了。

数据说话：Interop 2026 实施一年以来，头部引擎之间的标准合规差距从 6 分缩小到了 2 分（满分 100）。Anchor Positioning、View Transitions、Popover API、WebGPU 四个特性同批达标，是 Interop 有史以来单轮交付最完整的一次。

核心 API：三个属性一个规则

Anchor Positioning 的用法满大街都是，这篇不重复。只讲规范里最容易被忽视的几个点。

anchor-name：声明锚点

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

注意这里用的是 CSS 自定义属性语法，不是字符串。这个名字在当前 anchor-name 作用域内全局唯一。

position-anchor + anchor()：建立绑定

.tooltip {
  position: absolute;
  position-anchor: --my-anchor;
  top: anchor(bottom);
  left: anchor(center);
  translate: -50% 0;
}

anchor() 函数可以传两个参数：省略锚点名时默认用 position-anchor 指向的那个。

position-area：自动碰撞检测

这是替代 Floating UI flip() 中间件的核心能力。浏览器自动在可用空间里选一个位置：

.tooltip {
  position: absolute;
  position-anchor: --my-anchor;
  position-area: top span-right;
}

position-area: top span-right 的意思是「优先放顶部，如果放不下就按顺时针翻转到右侧」。浏览器在渲染时自动计算，不需要 JS。

@position-try：自定义备选方案

当 position-area 的自动翻转不够用时，手写备选：

@position-try flip-above {
  top: auto;
  bottom: anchor(top);
}
@position-try flip-left {
  left: auto;
  right: anchor(right);
}

.tooltip {
  position-try-orders: flip-above, flip-left;
}

删库对比：Floating UI vs CSS Native

Mintec 在 2026 年 Q2 做了三个客户项目的迁移实操，对比数据很清晰：

Bundle 节省不是 12KB 那么简单——你删掉依赖之后，Popper.js / Floating UI 带来的间接依赖、版本维护、升级测试也一并没了。Mintec 三个项目的平均结果：JS Bundle 减少约 31KB，组件代码行数从 20 行降到 8 行。

INP 收益：被忽视的隐形收益

大多数团队看到 12KB 的数字就决定不改了。但真正值得算的是 INP（Interaction to Next Paint）。

Floating UI 的 computePosition() 运行在微任务队列，每次调用都会触发一次 Layout Reflow。工具提示、Dropdown 打开——这些高频交互在低配手机上会直接拉高 INP。CSS Anchor Positioning 完全在渲染引擎里走，不占主线程，没有 JS 触发 reflow 的机会。

Google 的 Internal Data 显示，迁移到 CSS Anchor Positioning 的电商产品详情页，Dropdown 交互的 INP 中位数下降了 18%。

Safari 旧版本怎么办

Safari 18.2 和 18.3 支持 anchor() 和 position-anchor，但不支持 @position-try。有一个经过验证的渐进增强方案：

/* 基础位置：Safari 18.2-18.3 正常渲染 */
.tooltip {
  top: anchor(bottom);
  left: anchor(center);
}

/* @position-try 块：只有支持的浏览器才会执行 */
@supports (position-try-fallbacks: flip-block) {
  .tooltip {
    position-try-orders: flip-block;
  }
}

Safari 照常显示 tooltip，只是不自动翻转。Chrome / Firefox / Safari 18.4+ 有完整行为。这是合理的渐进增强，不是退化。

对于必须精确支持 Safari < 18.2 且要有完整翻转逻辑的少数场景，可以保留 Floating UI 作为 Legacy Fallback——但只加载给那部分用户：

if (!CSS.supports("anchor-name: --a")) {
  const script = document.createElement("script");
  script.src = "https://unpkg.com/@floating-ui/dom";
  document.head.appendChild(script);
}

现代浏览器零成本。只有落后于 2024 年的浏览器才加载 Polyfill。

迁移路径：不是推翻重来

Anchor Positioning 不能 100% 替代 Floating UI 的所有能力。虚拟元素（相对鼠标坐标、任意坐标定位）目前 CSS 不支持。如果你的 Dropdown 有自定义光标跟随逻辑，先别动。

真正适合迁移的场景：tooltip、popover、dropdown menu、callout、select 下拉——这些占 Floating UI 日常用量 90% 的组件，Anchor Positioning 可以直接替换。

推荐顺序：

第一步：新建组件用 CSS

从今天开始，所有新做的 tooltip 和 popover 直接用 Anchor Positioning，不装 Floating UI。三个 CSS 属性比一个 npm 依赖更好维护。

第二步：低风险存量迁移

找一个非核心页面（比如设置页、帮助页）的 Dropdown，用 Chrome DevTools 的 CSS Anchoring panel 对比原有行为。行为一致则替换，保留 3 天观察线上报错。

第三步：性能复盘

迁移完成后在 CrUX 或 web-vitals 里跑一遍 INP 数据，和迁移前对比。INP 降了才算迁对。

Interop 2026 真正改变了什么

回到开头的问题：既然 Anchor Positioning 2025 年就能用，为什么大多数团队到 2026 年还在装 Floating UI？

答案不是技术问题，是流程问题。

当一个团队的 tooltip 是三年前写的，用的是 Floating UI 2.x，后来的人看到「前辈装的依赖」就默认保留。一行 npm install 比研究浏览器兼容性数据容易多了。惯性才是最大的技术债。

Interop 2026 的贡献是提供了一张干净的验收单：四家引擎同一条线，没有「Chrome 可以用 Safari 暂时不行」的模糊地带。这张单子够干净，团队才有理由动那行 npm install。

当你下次打开 package.json 看到 @floating-ui/dom，问自己一个问题：这个东西解决的需求，2026 年的浏览器已经原生支持了，我为什么还在维护它？