前端面试：如何为 CSS Masonry 布局设计渐进增强？
题干与适用场景
产品希望做瀑布流图片墙：卡片高度不同，桌面多列、移动端单列，内容需要键盘和屏幕阅读器可用。CSS Grid Level 3 正在定义 Masonry 布局，但浏览器支持与语法仍需核对。请比较原生 CSS、列布局和脚本方案，并给出不支持时的回退与验证。
面试官考察点
- 是否区分视觉紧凑排列与 DOM、阅读和焦点顺序。
- 能否根据规范状态和实际支持做 feature detection，而非凭浏览器名称判断。
- 能否处理图片尺寸、CLS、响应式列数、虚拟化和重排成本。
- 是否把无脚本、键盘、屏幕阅读器和打印场景纳入验收。
回答前需要澄清的问题
- 卡片顺序必须按发布时间、优先级，还是允许按列视觉顺序变化？
- Masonry 是装饰性网格，还是用户需要按顺序阅读和操作的内容？
- 目标浏览器、无脚本要求和 SEO 约束是什么？
- 图片数量是否达到需要虚拟化、分页或懒加载的规模？
- 是否必须支持拖拽、插入、动态高度和打印？
30 秒回答框架
我会先固定语义 DOM 顺序，再用 CSS 做视觉布局。对支持的浏览器通过 @supports 选择 Masonry；不支持时回退到普通 Grid 或多列布局，并接受间隙差异。图片预留宽高，避免布局跳动；不把 JavaScript 作为无障碍必需路径。用键盘、读屏、缩放、打印和长列表测试视觉与 DOM 顺序是否仍一致。
分步骤深入解答
第一步：定义 Masonry 的取舍
Masonry 目标是让项目沿一个轴按网格轨道排列、沿另一个轴紧凑堆叠。它解决的是空白减少和视觉密度，不自动解决内容阅读顺序、焦点移动或可预测分页。先把这些产品约束写成验收标准，再选实现。
第二步：保持语义与焦点顺序
使用真实链接、按钮和标题，DOM 顺序按业务顺序输出。避免通过脚本重排节点或用正数 tabindex 修补视觉顺序。若视觉列顺序与 DOM 顺序不同，在设计上接受差异，或改用普通 Grid 保证逐行阅读。
第三步：做能力检测与回退
把实验性语法放在 @supports 中，并在目标浏览器矩阵实测。支持时使用规范推荐的 Masonry 语法；不支持时回退到 display: grid、固定轨道或列布局。回退应保持相同 DOM、内容和交互，差异只体现在空白与排列密度。
第四步：处理图片与动态高度
服务端输出图片宽高或 aspect-ratio，配合懒加载和合适的 object-fit，减少 CLS。图片加载、字体替换和内容更新会触发重排，长列表应分页或虚拟化。脚本测量布局时要节流，并避免读写布局交错导致强制同步布局。
第五步：评估性能与可维护性
对 CSS、列布局和脚本方案分别测量首屏、滚动帧率、布局耗时、内存和长列表插入。保留最小化的视觉差异说明，避免为每个断点复制规则。脚本方案只有在拖拽、跨列动画或旧浏览器要求确实需要时才启用。
第六步：覆盖无障碍与非视觉场景
用键盘逐项访问，验证焦点不跳跃；用屏幕阅读器确认标题、链接和图片替代文本按 DOM 顺序出现。放大到 200%、高对比、减少动效、打印和禁用脚本仍应可读。瀑布流不能成为获取内容的唯一方式。
第七步：发布与监控
记录规范版本、浏览器支持矩阵和回退策略。线上监控 CLS、LCP、脚本错误、布局溢出和卡片交互完成率，按浏览器分组观察。浏览器语法变化时先在实验环境回放截图和可访问性用例，再扩大范围。
高质量示范回答
我会保留按业务顺序的语义 DOM，并把 Masonry 作为视觉增强。用 @supports 和真实浏览器矩阵检测规范语法；不支持时回退到普通 Grid 或列布局，保持同一内容和交互。图片输出尺寸或 aspect-ratio 以降低 CLS，长列表用分页或虚拟化而非频繁同步测量。键盘、读屏、放大、打印和禁用脚本都必须能按 DOM 顺序获取内容。线上按浏览器监控 CLS、布局错误和交互完成率，规范更新先做回放和无障碍验收。
常见错误
- 只看视觉紧凑度，忽略 DOM、焦点和屏幕阅读顺序。
- 假设所有现代浏览器都支持同一 Masonry 语法，不做
@supports和实测。 - 用正数
tabindex或脚本搬运节点修补顺序。 - 图片没有尺寸，加载后导致大量 CLS 和重排。
- 为了兼容性引入常驻脚本，却没有测量其布局和内存成本。
追问及应对
追问一：为什么不用多列布局？
多列布局能产生瀑布流视觉，但内容按列分段，阅读和焦点顺序可能与业务顺序不同。若顺序重要，应优先普通 Grid 或接受空白。
追问二：如何判断 Masonry 语法可用？
使用 @supports 和目标浏览器自动化测试，按规范文档记录通过的属性和值。不能只按 User-Agent 或“现代浏览器”标签推断。
追问三：动态插入卡片怎么办？
保持 DOM 插入顺序，给图片预留尺寸，批量更新并避免逐项强制布局。长列表需要分页、虚拟化和可恢复焦点。
追问四：脚本回退什么时候合理？
当拖拽、复杂跨列动画或明确的旧浏览器支持要求无法由 CSS 满足时。脚本应是增强层，失败时仍保留语义内容。
追问五：如何证明无障碍没有被视觉布局破坏？
用键盘和屏幕阅读器按 DOM 顺序逐项操作，结合 200% 缩放、减少动效、打印和禁用脚本测试，并把结果纳入发布门禁。