anchor()不适合生产环境通用弹窗定位，因仅Chrome125+/Edge125+需手动开启实验标志，Safari/Firefox完全不支持；其适用场景限于动态跟随触发元素的Tooltip等，且必须搭配JS fallback。
目前不能在生产环境直接用 anchor() 实现“通用弹窗”，因为该 API 仍处于实验阶段，且兼容性极差 —— Chrome 125+ 和 Edge 125+ 需手动开启 chrome://flags/#enable-experimental-web-platform-features，Safari 和 Firefox 完全不支持，连基本解析都不做。
为什么 anchor() 不适合做弹窗定位主体
锚点定位不是“替代 position: absolute + transform”的方案，而是解决另一类问题：当弹窗需**动态跟随某个可移动/重排布的触发元素**（如工具提示、下拉菜单）时，才体现价值。普通模态框（Modal）是覆盖全屏、与触发源无位置绑定关系的，用它反而增加复杂度和风险。
-
anchor-name必须设在非display: none且带定位（position: relative等）的元素上；弹窗常由 JS 控制显隐，隐藏后锚点立即失效 -
anchor()只能在top/right/bottom/left/translate等属性中使用，不能用于width、margin或动画关键帧，限制极大 - 若弹窗祖先有
overflow: hidden或transform，部分浏览器会中断锚点跟随逻辑（Chrome 127 已修复部分，但旧版仍存在） - 没有 fallback 机制：一旦 flag 关闭或浏览器不识别，
anchor()规则被静默丢弃，弹窗直接塌缩到top: 0; left: 0
真正在用的锚点定位场景：工具提示（Tooltip）
这是当前唯一稳妥落地的用例 —— 触发元素固定可见、DOM 结构松散、需实时对齐、且允许降级为 JS 计算。
- 触发按钮必须设
anchor-name: --tooltip-trigger，且不能是display: none或visibility: hidden - 提示框必须为
position: absolute或position: fixed，static或relative下anchor()无效 - 正确写法示例：
top: anchor(--tooltip-trigger bottom); margin-top: 4px;，注意单位必须单独写，不能写成top: anchor(--tooltip-trigger bottom) + 4px - 降级方案必须存在：用
@supports not (top: anchor(--x top))包裹锚点规则，并在外层提供 JS 的getBoundingClientRect()补充逻辑
别踩坑：position-anchor 和 inset-area 已废弃
所有 2024 年前的教程里出现的 position-anchor: --x 或 inset-area: top 都已失效。Chrome 125 起只认函数式调用，且仅限特定属性。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
.tooltip { position-anchor: --x; inset-area: top; }→ 浏览器忽略整条规则，无警告 - 正确写法：
.tooltip { position: absolute; top: anchor(--x bottom); left: anchor(--x center); translate: -50% 0; } -
anchor-size()同样受限，只能用于width、height、min-width等尺寸属性，不能用于padding或font-size - 名称严格区分大小写且必须带
--前缀：--Tooltip≠--tooltip，tooltip直接无效
真正麻烦的不是语法，而是你得同时维护两套定位逻辑：一套是现代浏览器的 anchor()，另一套是所有其他环境的 JS fallback —— 这意味着哪怕只加一行 anchor()，也得配套写好 ResizeObserver 和 scroll 监听。对于弹窗这种高交互组件，投入产出比极低。
