题干与适用场景
你负责一个响应式 Web 应用：点击头像打开菜单，菜单必须跟随头像移动，在窄视口不能被裁切，还要支持从左到右和从右到左的书写方向。假设菜单由 Popover 或现有交互控制显隐；本题只讨论定位、换位与降级。目标岗位是前端工程师，考察 CSS 布局模型、可访问的边界处理和渐进增强。
面试官考察点
强回答会先区分“谁控制显隐”和“谁计算几何位置”，再用 anchor-name 建立关系，用逻辑方向的 position-area 或 anchor() 放置目标，用 position-try 处理空间不足。候选人还应说明 Anchor Positioning 解决的是布局耦合，不会自动替代键盘焦点、Popover 生命周期或浏览器兼容策略。只背属性名、把它说成所有浏览器都支持，属于风险信号。
回答前需要澄清的问题
- 菜单是否必须兼容不支持 Anchor Positioning 的浏览器？若必须，保留普通流或 JavaScript 测量的降级路径。
- 菜单是否允许脱离锚点的滚动容器？若锚点与目标不在同一定位上下文，需检查 containing block 与裁切边界。
- 是否支持 RTL 和垂直书写？若支持，优先逻辑值
block-end、inline-start，避免固定left与right。 - 菜单是绝对定位还是固定定位？两者的滚动参照物不同，影响滚动容器和视口边缘行为。
30 秒回答框架
“我把头像设为 anchor，把菜单设为 anchored element。先用 position-area 表达默认位置，再用 position-try 声明空间不足时的备选位置；需要精确对齐时改用 anchor() 和逻辑 inset。显隐仍由 Popover 或组件状态负责。上线前用 @supports 保留旧方案，并测试滚动、RTL、窄视口、缩放和键盘焦点。”
分步骤深入解答
先给按钮命名，再把菜单连接到它：
.profile-button { anchor-name: --profile-button; }
.profile-menu {
position: absolute;
position-anchor: --profile-button;
position-area: block-end span-inline-end;
position-try: block-end span-inline-start;
}position-area 可以把锚点视为九宫格中心；block-end span-inline-end 表示菜单从块方向末端开始，并沿行方向向末端展开。position-try 让浏览器在首选位置空间不足时尝试另一侧。这个规则比用窗口宽度写多个媒体查询更接近约束本身：换位原因是可用空间，而不是某个固定像素。
需要边缘精确对齐时使用 anchor()：
.profile-menu {
position: absolute;
position-anchor: --profile-button;
inset-inline-start: anchor(start);
inset-block-start: anchor(end);
}position-area 适合表达“放在锚点哪一格”；anchor() 适合表达“目标的哪条边对齐锚点哪条边”。不要把两种心智模型混成一套坐标。目标可能比锚点宽，默认居中会造成视觉错位，此时 span-inline-end 或显式 inset 更可控。
降级必须与交互状态分离：
@supports not (anchor-name: --profile-button) {
.profile-menu { inset-inline-start: 0; inset-block-start: 100%; }
}这段降级只保证可见位置，不能假设它能处理所有溢出。若产品要求在旧浏览器中也自动换位，JavaScript 应测量 getBoundingClientRect()，选择位置后写入 CSS 自定义属性，并在 resize、scroll、字体加载和菜单尺寸变化时节流更新。新方案的优势是把测量与布局交给 CSS；代价是需要验证实现状态和旧浏览器路径。
高质量示范回答
我会先确认显隐由 Popover 或组件状态负责，定位问题单独解决。头像声明 anchor-name，菜单用 position-anchor 关联；默认用逻辑方向的 position-area 放在头像下方，再用 position-try 声明向另一侧展开的备选。菜单宽度与头像不同、需要严格边缘对齐时，我会改用 anchor()，而不是继续叠加 offset。兼容策略上用 @supports 提供稳定的普通定位；如果旧浏览器也必须自动避开视口，再加入基于测量的降级。验收会覆盖 RTL、滚动容器、缩放、窄视口、键盘焦点和动态字体，确认定位换位没有破坏可访问性。
常见错误
- 错误表现 → 把
position-anchor当成显隐 API → 失败原因是定位关系与交互状态是两层职责 → 修正方法是让 Popover、焦点管理和 CSS 定位分别可测试。 - 错误表现 → 只写
top、left并声称支持 RTL → 失败原因是物理方向不会随书写模式自动改变 → 修正方法是优先使用block-、inline-与逻辑position-area。 - 错误表现 → 用固定媒体查询模拟每个边缘 → 失败原因是菜单内容、缩放和滚动会改变真实可用空间 → 修正方法是用
position-try表达空间约束，旧浏览器再用测量降级。 - 错误表现 → 认为浏览器会替你处理焦点和屏幕阅读器语义 → 失败原因是 Anchor Positioning 只定义布局 → 修正方法是单独验收键盘导航、Escape 关闭和焦点回收。
追问及应对
追问一：菜单在滚动容器内被裁切怎么办？
先确认目标的 containing block 与 overflow 裁切边界。若菜单必须越过容器显示，调整定位上下文或使用固定定位，并重新验证锚点、滚动和焦点关系；只增加 z-index 无法穿过 overflow 裁切。
追问二：同一页面有多个头像，如何避免锚点串线？
为每个实例生成唯一的 anchor 名称，或用作用域限制可见锚点；组件销毁时清理关联样式。测试应同时打开相邻菜单，确认每个目标只跟随自己的锚点。
追问三：浏览器不支持 position-try 时如何发布？
把首选位置写成可接受的静态降级，使用 @supports 增强换位。若产品不能接受静态降级，就在能力检测后启用测量逻辑，并把差异记录在兼容性监控中，不把未支持浏览器静默当成成功。