正整数 tabindex（1–32767）会破坏键盘导航逻辑，强制元素前置并按数值升序排列，导致焦点顺序脱离视觉结构和语义流；多个相同值仅首项生效，其余降级为 tabindex="0"；动态渲染与 SSR 场景下难以维护，且干扰屏幕阅读器上下文理解；应优先使用 tabindex="-1" 配合 .focus() 精准控制。
tabindex="1" 到 tabindex="32767" 会破坏键盘导航逻辑
浏览器把所有正整数 tabindex 视为“强制前置”，不管它在 DOM 里多靠后，都会被提到整个 Tab 流最前面；多个正数按数值升序排列——tabindex="1" 在 tabindex="2" 前，但 tabindex="100" 和 tabindex="999" 并不意味着“最后聚焦”，只是排在它们之间。真正的问题不是排序不准，而是它让焦点顺序脱离视觉结构和语义流。
多个相同正数 tabindex（如全设为1）实际只生效一个
当页面中多个元素都写 tabindex="1"，浏览器不会按你预期“全部排第一”，而是只保留第一个匹配的，其余同值元素降级为 tabindex="0" 处理——结果是：焦点顺序又退回到 DOM 顺序，但屏幕阅读器仍会把第一个 tabindex="1" 当作逻辑起点，造成认知错位。
动态渲染场景下正数 tabindex 几乎不可维护
React/Vue 组件复用、模态框动态插入、卡片列表循环渲染时，若每个按钮都硬编码 tabindex="1" 或随意用 tabindex="5"，焦点顺序就取决于挂载时机而非结构意图。常见现象包括：
- 模态框打开后，焦点跳回页面顶部某个
tabindex="1"的导航链接，而非框内第一个按钮 - 折叠面板展开后，焦点停在标题上（因为写了
tabindex="1"），而不是新暴露的输入框 - 服务端渲染（SSR）生成的顺序与客户端 hydration 后的 tabindex 值不一致，触发可访问性警告
正整数 tabindex 让屏幕阅读器用户失去上下文
辅助技术依赖文档流理解页面结构。把页脚的“导出”按钮设成 tabindex="1"，用户一进页面就听到“导出”，完全不知道自己在哪、当前编辑的是什么内容。这不是“微调顺序”，是切断语义链。更麻烦的是：tabindex="1" 元素会被当作逻辑起点，但视觉上它可能藏在右下角或隐藏区域，导致键盘用户反复迷失。
立即学习“前端免费学习笔记（深入）”；
正整数 tabindex 看似可控，实则把焦点控制权交给了数字字面值，而非 DOM 结构或交互意图——而后者才是可访问性的根基。真正需要干预顺序时，该用的是tabindex="-1" 配合 .focus()，不是给一堆元素乱打编号。 
