根本原因是父容器未设display: grid或子元素被grid-row等显式定位覆盖；order仅对Grid直接子元素生效，且不改变DOM结构，但会影响焦点和屏幕阅读器顺序。
order属性为什么设了没反应
根本原因就一个：父容器没开 Grid 布局，或子元素被显式定位覆盖了。只要父元素没写 display: grid 或 display: inline-grid，order 就完全无效——CSS 不报错，也不提示，只是默默忽略。
更常见的是写了 grid-column 或 grid-row，比如：.item { grid-column: 2; order: -1; }。这时 order 仍被解析（DevTools 里能看到 computed 值），但布局阶段已被显式定位接管，order 失效。
- 确认父容器有
display: grid，光写grid-template-columns不够 - 检查子元素是否带
grid-column、grid-row、grid-area——任一存在即屏蔽order - 避免嵌套：子元素若自己是
display: flex容器，它的子项不是 Grid 直接子项，order不生效
用 JS 动态改 order 的正确姿势
靠预定义一堆 CSS 类（如 .top { order: -1; }）切换顺序，在真实交互中极易失控：类名叠加、优先级冲突、多排序逻辑打架。真正可靠的方式是 JS 直接操作 style.order。
- 用
element.style.order = "-1"赋值，字符串或数字都行，但统一用字符串可避免隐式转换问题 - 批量重排时，先算好所有项的
order值，再一次性写入 DOM，减少 layout 触发次数 - 别用
classList.toggle()控制排序——它无法表达“置顶 + 按时间降序”这种复合逻辑 - SSR 场景下，服务端渲染的
style.order不生效，需在客户端 hydration 后立即补设
order 影响可访问性顺序，这点常被忽略
order 改变的不只是视觉位置，还会同步改变 tab 键焦点顺序和屏幕阅读器朗读顺序。如果你只是想“看起来换位置”，但希望键盘用户仍按原始 HTML 结构操作，order 就不合适。
立即学习“前端免费学习笔记（深入）”；
- 手动 Tab 测试是必须步骤：看焦点是否跳到意料之外的位置
- Chrome DevTools 的 “Accessibility” 面板能直接显示当前 accessibility tree 的节点顺序
- 若语义顺序必须保持不变，改用
grid-column/grid-row显式定位，或直接调用container.insertBefore()调整 DOM 顺序 - 强行用
order又想保可访问性？得额外加aria-flowto或重构语义结构，否则 WCAG 会失败
grid-auto-flow 不是用来翻转已有项的
很多人以为把 grid-auto-flow 从 row 改成 column 就能让已渲染的网格项“竖着排”，其实它只影响**后续新加入的、未显式定位的项**如何填空，不会重排已有项。
- 已设置
grid-row: 1和grid-column: 2的元素，无论grid-auto-flow是什么值，位置都不变 - 用了
grid-template-areas后，grid-auto-flow对已命名区域内的项完全失效 - 真正需要横/竖切换响应式布局？应直接换整套网格定义，比如小屏用
grid-template-columns: 1fr+grid-auto-flow: column，大屏切回grid-template-columns: repeat(3, 1fr) -
dense模式慎用：它会让 DOM 后面的元素插进前面的空隙，破坏视觉与源顺序一致性，对可访问性和:nth-child()选择器都有干扰
