新浏览器里布局漂亮，旧浏览器却堆成一列，说明技术选型需要覆盖真实使用环境。
本文使用浏览器 JavaScript、HTML 与局部演示数据。前端复杂性常来自状态与异步关系，而不是组件数量。本文把服务器业务事实、页面查询条件和用户临时编辑分别表达，避免多个界面位置互相覆盖。
1. 从现象推到机制
渐进增强先提供可读可用的基础结构，再在支持时增加布局能力。CSS Grid（网格布局）与 Flexbox 适用维度不同，检测支持可以帮助选择样式，但不代表所有边界都一致。内容顺序不应依赖视觉位置才能理解。
图中的四个节点分别表示基础文档、能力检测、增强样式、回退验证。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
演示用普通块布局作为基础，在支持 grid 时改成两列。测试窄屏、长标题和缺图，不只看设计稿尺寸。
1
2
3
4
5
.cards > article { margin-bottom: 16px; }
@supports (display: grid) {
.cards { display: grid; grid-template-columns: 1fr 1fr; }
}
/* 保留不支持 grid 时的可读基础排布 */
先用不连接真实业务的小页面观察状态迁移，保存每次输入与渲染结果。组件拆分之后仍需验证整体任务，不能只检查每个按钮能响应。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 浏览器不支持网格 | 基础内容仍应可读可操作 |
| 标题特别长 | 需要检查最小尺寸和换行 |
| 视觉重排改变顺序 | 键盘与阅读顺序仍按 DOM 分析 |
对照 1：浏览器不支持网格
基础内容仍应可读可操作。观察时记录回退布局的任务完成情况。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：标题特别长
需要检查最小尺寸和换行。观察时记录实际内容而非短占位文字。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：视觉重排改变顺序
键盘与阅读顺序仍按 DOM 分析。观察时记录焦点顺序和内容语义。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
支持检测只判断语法能力，不能代替目标设备验证。对关键后台页面，稳定操作比追求最新布局效果更重要。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“视觉重排改变顺序”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
