order属性仅改变视觉顺序，不影响DOM、Tab键序、屏幕阅读器读取及SEO；其排序按负数>0>正数组分组，组内依HTML顺序；仅对网格直接子元素生效，需避免嵌套布局干扰和响应式重排抖动。
order属性只影响视觉顺序，不影响DOM顺序和可访问性
用 order 调整网格项显示位置，浏览器渲染时会重排视觉流，但源码里元素的顺序、键盘 Tab 顺序、屏幕阅读器读取顺序全都不变。这意味着：用户按 Tab 键仍按 HTML 书写顺序跳转，SEO 和语义结构也完全不受 order 影响。
实操建议：
- 仅在视觉重构有明确需求时使用
order（比如响应式下把侧边栏提到主内容前） - 如果排序逻辑本身有语义优先级（如“重要通知”必须先被读到），别靠
order，直接调整 HTML 结构 - 测试时务必手动 Tab 导航，确认焦点流是否符合预期；可用 Chrome 的“Accessibility”面板检查
accessibility tree中的节点顺序
order值默认是0，负数比正数靠前，相同值按HTML顺序排列
order 是整数，不支持小数或单位。它的排序规则不是“数值越小越靠前”那么简单——而是先分组：所有负数 > 所有 0 > 所有正数；组内再按 HTML 顺序稳定排序。
常见错误现象：设了 order: -1 和 order: 1，结果两个元素并排出现，没拉开距离——因为它们在不同行/列轨道上，order 只在同一个网格容器内横向比较，不跨轨道“抢位置”。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 避免用
order: -999或order: 999这类魔数，用小范围整数（如 -1 / 0 / 1）更易维护 - 当多个项目
order相同，它们会按 HTML 中出现顺序依次填入可用网格区域，这点和 flexbox 一致 - 注意 Grid 的
grid-auto-flow值：设为column时，order会影响列内顺序，而非行内
与其他布局方式混用时，order可能被忽略
如果网格项同时设置了 display: flex 或 display: grid，或者父容器用了 display: contents，order 行为会异常。最典型的是：父元素是 Grid，子元素又套了一层 Flex 容器，那子元素内部的 order 就不起作用——因为 order 是 Grid 和 Flex 的专用属性，只对直接子元素生效。
实操建议：
- 确认
order写在**网格直接子元素**上，而不是孙子节点 - 避免在同一个元素上同时启用 Grid 和 Flex（比如
display: grid+display: flex），后者会覆盖前者 - 慎用
display: contents：它会让子元素“冒泡”到父 Grid 容器中，此时原父元素上的order失效，需把order移到真正参与网格布局的节点上
响应式中用媒体查询切换order容易引发重排抖动
在 @media 里频繁修改 order 值（比如从 0 改成 2 再改回 0），会导致浏览器反复计算布局，尤其在低端设备上可能出现短暂闪动或卡顿。这不是 bug，而是 CSS 重排的自然开销。
实操建议：
- 优先用
grid-template-areas或grid-row/grid-column显式定位替代order切换，它们更稳定、意图更清晰 - 如果必须用
order响应式切换，加transition: order 0.2s并配合will-change: order（仅限必要场景，别滥用） - 测试真机横竖屏切换，观察是否因 layout thrashing 导致滚动卡顿
order，而是判断该不该用它——一旦涉及语义、导航、动画或嵌套布局，它就很容易变成隐藏的耦合点。 
