tabindex不是微调焦点顺序的工具，而是修复焦点流断裂或赋予非可聚焦元素键盘可访问性的手段；滥用正数tabindex（如全设为1）会破坏可访问性，导致焦点顺序错乱与认知断层。
直接说结论：tabindex 不是用来“微调顺序”的工具，而是用来修复默认焦点流断裂、或为非可聚焦元素（如 div）赋予键盘可访问性的手段。滥用正数 tabindex（比如全设成 1）会破坏可访问性，反而让屏幕阅读器用户更难导航。
tabindex="1" 是最常见也最危险的写法
很多人一上来就给所有按钮加 tabindex="1"，以为这样就能“统一控制顺序”。结果是：所有元素都挤在 Tab 流最前面，彼此顺序又按 DOM 位置排——和没设一样，还多了一层误导。
-
tabindex="1"不代表“第一个”，只代表“比0和负值优先”，多个1时仍按 HTML 出现顺序走 - 一旦页面里混用
tabindex="1"、tabindex="2"、tabindex="0"，焦点顺序就变成“正数升序 → DOM 顺序 → 0 值元素 → 负值忽略”，极易错乱 - 屏幕阅读器会把
tabindex="1"的元素当作“逻辑起点”，但视觉上它可能在页脚，造成认知断层
什么时候该用 tabindex="0"
这是最安全、最推荐的显式设置方式，适用于两类场景：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 想让一个原本不可聚焦的容器（比如
<div class="card">）能被 Tab 键选中，且保持自然 DOM 顺序 —— 直接加 <code>tabindex="0" - 修复因 CSS
visibility: hidden或 JS 动态移除又恢复导致的焦点丢失问题：恢复元素后手动element.tabIndex = 0，再element.focus() - 注意：
tabindex="0"不改变原有顺序，只是“补位”。如果父容器已含button这类原生可聚焦子元素，父容器本身无需加tabindex，否则会重复进入 - 典型用法：模态框打开时，把焦点移到第一个可操作元素；关闭时，把焦点切回触发按钮 —— 触发按钮常需临时加
tabindex="-1"再恢复 - 错误用法：用
tabindex="-1"试图“隐藏”表单项来规避验证 —— 它不阻止 JS 访问，也不影响表单提交，纯属心理安慰 - 兼容性提醒：IE8 及更早版本不支持
tabindex="-1"的聚焦行为，若需兼容，得配合focus()+scrollIntoView() - 元素在
overflow: hidden的父容器内 - 页面有
position: sticky导航栏，遮挡了顶部区域 - 元素初始
display: none，JS 显示后未重排流
tabindex="-1" 的真实用途不是“禁用”，而是“临时聚焦”
设 tabindex="-1" 后，元素无法通过 Tab 键到达，但它依然能被 JavaScript 主动聚焦（element.focus()），而且 onfocus 事件照常触发。
focus() 后元素看不见？别忘了 scrollIntoView
element.focus() 只管聚焦，不管滚动。尤其在以下情况，焦点进了但用户完全看不到：
正确做法是聚焦后立刻调用：element.scrollIntoView({ block: 'nearest', inline: 'nearest' })。不要用 { behavior: 'smooth' }，它会和焦点动画冲突，导致滚动卡顿或失效。
