order属性仅影响自动流中网格项的视觉排序，不改变其网格位置；显式定位（如grid-column）会完全禁用order；负值仅用于分组，不对应负网格线。
负数序号根本不能用于定位隐式网格项
因为 order 属性只影响“参与自动流”的网格项的**视觉排列顺序**，它不生成、不移动、也不指定任何网格线或轨道位置。所谓“负数序号定位”，本身就是对 order 的误读——order: -1 不等于 “放到第 -1 行”，它只是把该项放进“负数组”，然后按 HTML 源顺序填入下一个可用的自动流单元格。
隐式网格项（即未被 grid-row/grid-column 显式放置、也未被 grid-area 命名区域捕获的子元素）确实会进入自动流，但它们的位置由 grid-auto-flow + order + HTML 顺序共同决定，而非由 order 数值直接映射到某条网格线。
-
order的数值不对应任何网格线编号；CSS 网格线始终从1开始正向编号，不存在-1、-2线 - 试图用
order: -99把元素“塞进第一行第一列”是无效的：如果第一行已被其他项占满，它会顺延到第二行第一个空位，哪怕你设了order: -999 - 若容器设置了
grid-template-rows: 100px 100px（仅两行），而自动流中第 3 个项的order是负数，它仍会落入隐式第三行——这个隐式行不会因order为负就“提前创建”或“倒序插入”
为什么你看到“负数没效果”，其实是显式定位在干扰
最常见的假象是：给一个子元素写了 order: -1，但它死活不往前走。大概率是因为它同时写了 grid-column: 3 或 grid-area: sidebar ——只要存在任一显式定位声明，order 就完全失效。
浏览器的处理逻辑非常明确：先执行显式分配（grid-row、grid-column、grid-area），再对剩下走自动流的项按 order 分组排序。一旦你把某个元素“钉”在第 5 列，它就不再参与 order 排序流程。
立即学习“前端免费学习笔记（深入）”；
- 检查 computed styles 中
grid-row-start和grid-column-start是否为auto：如果不是，说明该元素已被显式定位，“锁死”了 - 临时移除所有
grid-row、grid-column、grid-area声明，再测试order是否生效 - 注意
display: contents会让元素“消失”，其子节点冒泡成网格项——此时原order已无作用对象
真正想控制隐式网格项落点，得靠 grid-auto-flow 和命名线
如果你需要让某个自动流项出现在特定区域（比如“所有负序号项都进 header 区域”），order 无法做到。正确路径是放弃 order，改用显式结构：
- 用
grid-template-areas定义命名区域（如"header header" "main sidebar"） - 给目标子元素加
grid-area: header，它就会进对应区域，与order无关 - 若必须动态切换位置，用 JS 切换
grid-area值，比依赖order更可控 -
grid-auto-flow: dense可能让你误以为order生效了——其实只是它回头填空导致视觉上“跳前”，但这不可预测，且会破坏源顺序语义
order 负值唯一可靠的用途：分组+源序微调
order: -1 和 order: -5 在行为上完全等价：它们同属“负数组”，渲染时谁在 HTML 里写得靠前，谁就视觉靠前。这不是 bug，而是规范定义的分层排序逻辑。
- 多个
order: -1元素，按 HTML 顺序依次填入可用网格单元 - 混合使用
order: -1、order: 0、order: 1，才能形成三段式分组：所有负数 → 所有零 → 所有正数 - 避免用
order: -100和order: 999这类极端值——既无额外效果，又增加维护成本 - 响应式中覆盖
order时，务必确保选择器优先级一致，否则媒体查询里的设置可能被桌面端更具体的选择器覆盖
最常被忽略的一点：即使 order 在 computed styles 里显示正常，只要父容器没设 display: grid，或子元素脱离了格式化上下文（position: absolute、display: contents），它就彻底不参与布局计算——而浏览器连 warning 都不抛。
