tabindex="0"是使非原生元素进入Tab流的唯一合理方式，需同步添加role、keydown监听和:focus样式；tabindex="-1"用于动态聚焦，禁用正整数tabindex，聚焦顺序应由DOM结构决定。
tabindex="0" 是让非原生元素进 Tab 流的唯一合理方式
原生可聚焦元素（<button></button>、<a href></a>、<input>）默认就在 Tab 流里，加 tabindex="0" 不仅多余，还可能干扰 SSR 或框架 hydration 一致性。只有 <div>、<code><span></span> 这类语义容器需要手动加入时才用它。
但加了 tabindex="0" 并不等于“能用了”——必须同步做三件事：
- 加
role属性，比如role="button"，否则屏幕阅读器读作“无角色元素” - 监听
keydown，对Enter和空格键（' '）都做响应，并调用e.preventDefault()防止空格滚动页面 - 提供
:focus-visible或至少:focus样式，否则键盘用户完全看不到焦点在哪
tabindex="-1" 是动态聚焦的唯一安全入口
它让元素不能被 Tab 键触达，但能被 element.focus() 主动聚焦。这是模态框、折叠面板、下拉菜单等场景的核心机制。
常见错误是：模态框打开后调用 modal.querySelector('button').focus() 失败，控制台没报错，焦点也没动——大概率因为那个按钮是 <div>，没设 <code>tabindex="-1"，导致 .focus() 无效。
立即学习“前端免费学习笔记（深入）”；
关键操作点：
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 只对当前需临时聚焦的元素设
tabindex="-1"，其他保持默认 - 模态框关闭时，记得移除或重置该属性，否则下次打不开
- 别和
aria-hidden="true"同时用——前者允许聚焦，后者告诉读屏软件忽略，两者冲突 -
focus({ preventScroll: true })在 Safari 中不支持，传对象参数会静默失败；生产环境建议先检测：if ('preventScroll' in FocusOptions.prototype)
正整数 tabindex（如 1、2、999）必须禁用
它不是“提前排队”，而是把所有正数元素强行插到 Tab 流最前面，并按数值升序排列。结果往往是：用户从顶部开始 Tab，突然跳到页脚的 tabindex="1" 按钮，再按一次又回到顶部的另一个 tabindex="1" —— 完全脱离视觉和语义顺序。
更麻烦的是动态场景：
- 多个组件各自设
tabindex="1"，浏览器只保留第一个，其余降级为tabindex="0"，顺序不可控 - React/Vue 动态挂载后，DOM 插入顺序和 tabindex 值不一致，焦点错位警告频发
- 移动端 Safari 对正 tabindex 支持不稳定，部分版本直接忽略
- 屏幕阅读器用户依赖文档流理解上下文，强行把页脚按钮塞到第一个位置，等于剥夺其结构感知能力
真正可控的聚焦顺序靠 DOM 位置 + tabindex="0"
键盘导航的预期路径，本质是用户阅读/操作的逻辑流：筛选区按钮应在筛选结果上方，提交按钮应在表单底部。这不是靠 tabindex “拖拽”出来的，而是靠 HTML 结构本身表达的。
容易被忽略的细节：
- 用
CSS order或flex-direction: column-reverse改变视觉顺序时，DOM 顺序不变 → 键盘导航和读屏仍按原始 DOM 走，必须同步调整 HTML 结构 -
visibility: hidden或opacity: 0的元素不会自动退出 Tab 流，需手动加tabindex="-1"或aria-hidden="true" -
display: none的元素自动脱离焦点流，但 JS 调用.focus()会静默失败，哪怕有tabindex="-1" - 用
document.activeElement检查当前焦点，比肉眼 Tab 测试更可靠，尤其在异步渲染后
