不能。tabindex属性无法重新排列dom节点的焦点顺序，浏览器严格按html源码顺序遍历tabindex="0"和正整数元素，其值仅决定是否加入及相对插入位置，不改变dom线性结构。
不能。tabindex 属性无法“重新排列”DOM 节点的焦点顺序——浏览器严格按 HTML 源码中元素的出现顺序（即 DOM 顺序）遍历所有 tabindex="0" 和正整数元素，tabindex 的值只决定“是否加入”和“相对插入位置”，不改变 DOM 本身的线性结构。
为什么 tabindex="1"、tabindex="2" 不等于视觉/逻辑顺序重排
正整数 tabindex 会让浏览器把所有该值元素“提前”塞进 Tab 流开头，再按数值升序排列；但多个相同值（如全设 tabindex="1"）时，仅第一个生效，其余退回到 DOM 顺序。结果往往是：页脚的导出按钮比主表单第一项还早被 Tab 到，且一旦新增一个 tabindex="0" 元素，整个流就断层。
- 浏览器不读取 CSS
order、grid-area或flex-direction，只解析 HTML 字节流顺序 - React/Vue 动态渲染时，若
tabindex写死为正数，组件重排序或条件渲染会导致焦点路径不可预测 - 屏幕阅读器依赖 DOM 顺序理解上下文，强行插队会让视障用户丢失语义连贯性
真正可控的焦点流转靠结构 + tabindex="-1" + JS 聚焦
想让焦点从「城市」字段跳到「帮助按钮」再落到「邮编」，不能靠给按钮设 tabindex="2"，而应让按钮保持 tabindex="-1"，在「城市」的 blur 或 keydown 中显式调用 .focus()：
document.getElementById('city').addEventListener('blur', () => {
document.getElementById('help-btn').focus();
});
-
tabindex="-1"是唯一安全的编程聚焦入口：它不污染主 Tab 流，又允许.focus()成功触发 - 必须确保目标元素已挂载到 DOM（可用
requestAnimationFrame包裹.focus()） - 聚焦后若被
overflow: hidden或transform遮挡，需补element.scrollIntoView({ block: 'nearest' })
哪些元素根本不需要 tabindex
原生可聚焦元素（<button></button>、<a href></a>、<input>、<select></select>、<textarea></textarea>）默认等效于 tabindex="0"，手动添加是冗余；加 tabindex="-1" 则等于主动踢出 Tab 流，除非你明确要临时禁用其键盘访问。
- 伪控件（如
<div role="button">）才需要 <code>tabindex="0"，且必须同步加role、监听keydown（Enter/Space）、提供:focus-visible样式 - 禁用状态用
disabled或aria-disabled="true"，而不是靠tabindex="-1"模拟 - 纯展示型容器（头像
<div>、图标 <code><span></span>）不该加tabindex="0"，否则增加无意义焦点停顿最常被忽略的一点：焦点顺序错乱，90% 源于 DOM 顺序和视觉/操作逻辑不一致，而非
tabindex值没设对。先重构 HTML 结构，让语义上连续的字段在源码中相邻，再用tabindex="-1"和.focus()做精准接管——这才是复杂文档里真正可靠的做法。
