order只改视觉渲染，不改变键盘tab顺序，后者严格按html源码顺序执行；其原理是浏览器焦点管理器基于dom树而非css渲染结果工作，故设order:-1的元素若源码位置靠后，tab仍先聚焦其前元素。
不会影响。 order 只改视觉渲染顺序，键盘 Tab 顺序完全按 HTML 源码顺序走——这是规范行为，不是 bug。
为什么键盘焦点不跟着 order 走
浏览器的焦点管理器（focus manager）读取的是 DOM 树结构，不是 CSS 渲染结果。order 属于呈现层干预，不修改节点位置、不触发 DOM 重排，所以 Tab 键从上到下、从左到右遍历的仍是原始 HTML 书写顺序。
- 你给
<aside></aside>设order: -1拉到顶部，但它的 DOM 位置还在<main></main>后面 → Tab 仍先聚焦<main></main> - 表单里把
<button></button>的order设成最小，它在视觉上第一个，但若源码在最后，Tab 依然会跳过它或最后才到 - Chrome DevTools 的「Elements」面板里拖动元素改变位置，Tab 顺序也不变 —— 这和
order是同一类“仅视觉”操作
哪些场景容易误以为 Tab 顺序变了
实际是其他因素干扰了焦点流，和 order 无关：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
tabindex值被显式设置（比如tabindex="1"），覆盖了默认顺序 - 父容器用了
display: contents或visibility: hidden，导致某些元素退出可聚焦流 - JS 动态调用了
element.focus()，手动接管了焦点 - Flex 容器本身设了
flex-direction: row-reverse，改变了主轴方向 →order的“靠前”含义翻转，但 Tab 顺序依然不变
怎么验证 Tab 顺序是否真符合预期
别只看页面长什么样，要实测：
- 关掉鼠标，纯用
Tab/Shift+Tab走一遍，记下焦点路径 - 打开 Chrome DevTools → 「Accessibility」面板 → 点击任意元素，看右侧「Keyboard focusable」和「Focus order」字段
- 用 VoiceOver（macOS）或 NVDA（Windows）朗读整个页面，听它读的顺序是否和视觉一致
- 检查 DOM 中
<input>、<button></button>、<a></a>的物理位置，它们必须按逻辑优先级排列
事情说清了就结束。order 是视觉层的微调工具，不是焦点调度器；真正要控制键盘访问顺序，得动 HTML 结构或用 tabindex 显式声明，而不是指望 CSS “顺便”改掉它。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
