视觉排序不等于键盘焦点顺序，Tab键始终按HTML源码顺序跳转，CSS重排不影响可访问性；安全使用order仅限同网格行/列内平级元素微调，结构性切换必须调整DOM结构。
视觉排序 ≠ 键盘焦点顺序
用 grid-template-areas 或 order 调整网格项位置后，Tab 键仍按 HTML 源码顺序跳转——这是规范行为，不是 bug。屏幕阅读器、SEO 抓取、甚至部分辅助技术都完全无视 CSS 层的重排。如果你把页脚元素用 grid-area: header 强行“顶到顶部”，键盘用户第一次 Tab 仍会聚焦在原始 HTML 里排第一的导航栏（哪怕它被 CSS 放到了底部）。
哪些场景能安全用 order？
order 只适合同一网格行/列内做微调，比如主内容居中、操作按钮靠右，且这些元素语义上本就是平级兄弟关系。它不适用于结构性切换（如移动端把侧边栏提到顶部）。常见误用：
- 给
.sidebar设order: -1，但没同步调整 DOM 顺序 - 在响应式中仅靠媒体查询改
order，却忽略键盘用户缩放后焦点流错乱 - 对嵌套 grid 容器里的子项滥用
order，结果被外层grid-auto-flow覆盖
真正要兼顾可访问性，得动 DOM
如果页面必须支持键盘导航或读屏器，唯一可靠方式是同步调整 HTML 结构。可以用 JS 动态移动节点：
document.querySelector('.main').parentNode.insertBefore(document.querySelector('.sidebar'), document.querySelector('.main'));或者构建时输出两套结构：桌面端 HTML 为 <header><nav><main><aside><footer>，移动端改为 <header><aside><main><footer>。别指望 CSS “看起来对”就能过关——可访问性检测工具（如 axe）会直接报 focus-order-mismatch 错误。
display: contents 是个折中解法
当需要小屏下“融合”某个区块（比如广告位）进主网格又不想破坏语义顺序时，display: contents 比 order 更干净：它让父容器不生成盒模型，子元素直接成为网格项，可被重新分配到任意 grid-area。但注意 IE 不支持，且必须确保子元素本身有明确语义（比如不能把 <div class="ad"> 直接设为 display: contents 后丢进 main 区域而不加 role="region" 或 aria-label）。
立即学习“前端免费学习笔记（深入）”；
实际项目中最容易被忽略的点是：可访问性修复必须从 HTML 源码出发，CSS 只负责呈现。任何试图用纯样式“模拟逻辑顺序”的方案，在真实键盘操作或读屏环境下都会暴露问题。
