Flex 的 order 属性可纯 CSS 重排视觉顺序，不影响 DOM 和可访问性；需注意主轴方向、默认 order 值、移动端优先策略及避免与 display: contents 混用，复杂场景推荐 Grid 的 grid-template-areas。
媒体查询里用 order 改变 Flex 子项顺序最直接
Flex 布局是唯一能靠纯 CSS 在不改 HTML 结构的前提下，真正“重排”视觉顺序的方式。order 属性控制子元素在主轴上的排列次序，数值越小越靠前。它不改变 DOM 顺序，只影响渲染流，对可访问性和 SEO 友好。
常见错误是把 order 和 flex-direction 混用，比如在 column 下还按行序写 order: 1、order: 2，结果没变化——因为主轴已变成垂直方向，排序逻辑不变，但视觉表现容易误判。
- 必须给父容器设
display: flex或display: inline-flex - 所有要参与重排的子元素都得显式设置
order，否则默认值为0，可能意外挤到前面 - 移动端优先时，通常先写默认顺序（如侧边栏在右），再在
@media (max-width: 768px)里把侧边栏order设为-1提到顶部 - 不要依赖
order做复杂多层嵌套排序，超过 3–4 个区块就容易失控，此时该考虑 JS 或服务端响应式
Grid 布局用 grid-template-areas 更适合板块级重排
当页面有明确“头部/主内容/侧边栏/底部”这类语义区块时，grid-template-areas 比 order 更直观、更易维护。它通过字符串模板定义区域位置，媒体查询中只需替换模板字符串即可完成整块重排。
典型陷阱是区域名拼写不一致：比如默认写 "header main sidebar"，响应式里写成 "header main" 却忘了删掉 sidebar 的 grid-area: sidebar 声明，导致该区块消失或错位。
立即学习“前端免费学习笔记（深入）”；
- 每个子元素必须用
grid-area显式命名，且名字和grid-template-areas中的一致 - 模板字符串每行代表一行网格轨道，空格分隔列，引号必须成对，不能换行写
- 移动端常把三栏变单栏：
"header" "main" "sidebar" "footer"，注意sidebar要保留在模板里，否则它不会渲染 - IE 不支持
grid-template-areas，若需兼容，得 fallback 到 Flex 或 JS
display: contents 不是重排方案，慎用
有人想用 display: contents 把某个容器“抽掉”，让它的子元素直接成为父容器的子项，再配合 order 排序。这在技术上可行，但实际中极易出问题：它会让该容器失去盒模型、无法设置宽高/边框/背景，更重要的是，屏幕阅读器会跳过整个容器及其语义（比如 nav 或 aside）。
错误现象包括：键盘焦点丢失、NVDA/JAWS 读不出导航链接、打印样式错乱。这不是布局技巧，而是可访问性地雷。
- 除非你明确知道该容器没有任何语义需求，且测试过主流读屏软件行为，否则别用
- 替代做法是用 Flex/Grid 直接包裹真实子元素，避免中间冗余包装
- 如果 HTML 结构真绕不开，宁可用 JS 动态移动
Node，也比display: contents隐患小
重排后记得检查焦点顺序和滚动锚点
视觉顺序变了，但用户按 Tab 键的焦点流还是按 DOM 顺序走。如果主内容区块在 HTML 里排第三，但用 order 提到了第一，用户第一次 Tab 还是会聚焦到导航链接，而不是主标题——这会让键盘用户困惑。
另一个容易被忽略的是 scroll-behavior: smooth 和锚点跳转。比如页面有 #main 锚点，重排后主内容区块位置变了，但浏览器仍按原始 DOM 位置计算滚动目标，可能导致跳转偏移。
- 用
tabindex="-1"手动修正关键锚点元素的焦点可达性（仅限必要处） - 锚点跳转前，可用
getBoundingClientRect()校验目标位置，必要时加scrollIntoView({ block: 'start' })强制重算 - 别指望媒体查询自动同步焦点逻辑，这部分必须手动验证，尤其在折叠/展开侧边栏等交互后
真正的难点不在怎么写那几行 CSS，而在于重排之后，页面是否还“认得清自己”——DOM 顺序、焦点流、锚点、打印样式、读屏逻辑，全得重新对一遍。漏掉任何一环，用户感受到的就不是适配，而是错乱。
