order仅改变视觉顺序，不影响DOM结构、Tab焦点和屏幕阅读器顺序；生效前提为父容器设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——虽语法合法，但无语义优势，还易引发协作困惑
Grid 中 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 顺序仍按原始 HTML 流，但视觉首屏已是另一块内容，极易迷失
-
order不支持transition，强行加动画只会触发 layout thrashing，Chrome DevTools 的 “Paint flashing” 会大片亮红 - 移动端 Safari 旧版本（iOS 12 及更早）在快速切换
order时可能出现闪动或顺序错乱 - 真要动态重排，优先用 JS 直接写
el.style.order = "2"，比 class 切换更可控；批量操作务必一次性写入，避免多次重排
真正容易被忽略的，是把 order 当成语义重排工具——它只管“眼睛看到什么”，不管“键盘怎么走、屏幕阅读器怎么读、搜索引擎怎么抓”。需要兼顾三者时，grid-area + 多套模板，或 DOM 重排，才是更诚实的选择。
