order属性生效需满足三前提：父容器设display:grid/inline-grid、目标为直接子元素、未用grid-row/column/area显式定位；其排序按负数>0>正数分组，组内依HTML源序排列，不改变DOM、焦点或屏幕阅读器顺序。
直接用 order 属性是最常用、最轻量的方式，但必须满足三个硬性前提：父容器设了 display: grid（或 inline-grid），目标是直接子元素，且该元素没被 grid-row、grid-column 或 grid-area 显式定位。
为什么写了 order 却没效果？
这不是 CSS 写错了，而是布局上下文没到位。最常见的情况是：
- 父容器只写了
grid-template-columns或gap，但漏了display: grid——浏览器根本不识别为 Grid 容器，order被完全忽略 - 某个子项加了
grid-column: 2或grid-area: "header"——显式定位优先级高于order，它已“锁定位置”，不再参与自动排列 - 子项外层多套了一层
<div class="wrapper">，而order写在了.wrapper上——order只对 Grid 容器的**直接子元素**生效，中间插一层就断链 - 调试时打开 Chrome DevTools → Computed → 搜索
order，如果显示0 (initial)且无“inherited”字样，说明压根没生效；如果值存在但没变化，大概率是被显式定位覆盖了
order 的排序逻辑不是“数值越小越前”那么简单
它实际按三组分层比较：所有负数 > 所有 0 > 所有正数；每组内部严格按 HTML 源码顺序排列。这意味着：
-
order: -1和order: -99都在“负数组”，谁在 HTML 里写在前面，谁就视觉靠前（除非跨轨道） -
order: 0是默认值，不写等价于order: 0；多个order: 0元素按源码顺序填入可用网格单元 -
order: 1和order: 2只表示都在“正数组”，且前者略靠前——但不会“拉开距离”，它们可能被分到不同行/列而并排显示 - 避免用浮点数如
order: 1.5：语法虽合法，但无实际分组意义，还易引发协作困惑
grid-auto-flow 怎么影响 order 生效范围？
order 只在自动放置（auto-placement）阶段起作用，而 grid-auto-flow 决定了这个阶段的填充方向和分组逻辑：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
grid-auto-flow: row（默认）：order按行内从左到右比较，仅在同一行内生效 -
grid-auto-flow: column：order按列内从上到下比较，不同列之间不跨列排序 -
grid-auto-flow: row dense或column dense：浏览器会主动“填空”，把后面 DOM 中的项往前插，导致视觉顺序和 DOM 顺序彻底错位——这对键盘导航、屏幕阅读器都是灾难
什么时候不该用 order？
当真实需求涉及可访问性、SEO 或逻辑依赖时，order 就是错误工具：
- 不能靠
order把页脚提前显示——屏幕阅读器、Tab 键导航、SEO 解析仍按原始 DOM 流进行 - 用媒体查询切换
order值来实现“桌面端侧边栏在右、移动端移到顶部”，会导致焦点管理断裂：用户缩放页面后 Tab 键突然跳到中间某块内容，完全不可预测 - 如果模块本身用了
display: flex或嵌套了display: grid，order必须写在它的父容器（即首页主 Grid 容器）的直接子元素上，不能写在模块内部的子节点上
真正容易被忽略的点是：order 不是“重排”，只是视觉错觉；它触发重排的成本比想象中高，尤其在项数多、有跨行跨列时，帧率容易骤降；而 grid-template-areas 这类显式模板一旦启用，order 就彻底失效——此时该换思路，而不是硬调数值。
