order属性仅改变grid容器内直接子元素的视觉顺序，不改变dom、焦点或屏幕阅读器顺序；生效前提是父容器设display: grid，且子元素未被显式定位或区域模板覆盖。
order 属性能改视觉顺序，但不能动 DOM、Tab 焦点或屏幕阅读器顺序——它只是 CSS 层的“视觉重排”，不是真实结构调整。
为什么写了 order 却没效果
最常见原因是父容器没启用 Grid 布局。仅写 grid-template-columns 或 gap 不够，必须显式设置 display: grid（或 inline-grid）。
- 子元素的
order只对 Grid 容器的直接子元素生效；嵌套一层div就失效 - 如果子元素同时设置了
grid-row、grid-column或grid-area，order会被完全忽略——显式定位优先级更高 -
grid-template-areas已定义区域时，order对区域内元素无效 - 父容器用了
display: contents，子元素“冒泡”进外层 Grid，原order位置错乱，需移到真正参与布局的节点上
order 的排序逻辑不是“数值越小越前”那么简单
它的实际分组规则是：所有负数 > 所有 0 > 所有正数，组内再按 HTML 源顺序稳定排列。
-
order: -1和order: -99都属于“负数组”，谁在 HTML 里靠前，谁就视觉靠前（除非跨轨道） -
order: 0是默认值，不写等价于order: 0；多个order: 0元素严格按源码顺序填入可用网格单元 -
order: 1和order: 2并不会让它们“拉开距离”，只表示都在“正数组”里，且前者比后者略靠前 - 避免用浮点数如
order: 1.5——虽语法合法，但无语义优势，还易引发协作困惑
order 和 grid-auto-flow 的配合陷阱
order 只在自动放置（auto-placement）阶段起作用，而 grid-auto-flow 决定了这个阶段的填充方向和分组逻辑。
-
grid-auto-flow: row（默认）：order按行内从左到右比较，同一行内生效 -
grid-auto-flow: column：order按列内从上到下比较，不同列之间不跨列排序 - 设了
grid-auto-flow: column dense后，order行为更难预测——浏览器会主动“填空”，可能把高order值的项提前塞进空隙 - 横向布局下给 5 个项分别设
order: 4到order: 0，结果发现前两个并排显示——因为它们被分到了不同行，order不跨行竞争
响应式切换 order 时的真实代价
用媒体查询来回切 order 值，表面看是“纯 CSS 方案”，实则埋了可访问性和性能双坑。
- 键盘用户缩放页面后 Tab 键可能跳到意料之外的位置，焦点流不可预测
- 频繁修改
order会触发重排（reflow），尤其在低端设备上可能出现短暂闪动或卡顿 - 若真实需求是“移动端把导航放底部、桌面端放顶部”，别硬套
order；应优先用 JS 动态移动 DOM 节点，或服务端/构建时输出两套结构 - 测试时务必手动 Tab 导航，确认焦点流是否符合预期；可用 Chrome 的 “Accessibility” 面板检查 accessibility tree 中的节点顺序
真正容易被忽略的，是 order 在显式定位（grid-row/grid-column）和区域模板（grid-template-areas）面前毫无话语权——它只在“自动分配”的缝隙里起效。一旦你开始混合使用这些机制，视觉顺序就不再是单靠调一个数字能说清的事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
