加 tabindex="0" 仅适用于视觉可交互但非原生聚焦的元素；否则会导致焦点混乱。键盘操作需同时响应 enter 和 space（后者须 preventdefault）。模态框须实现焦点进出闭环。:focus-visible 是可访问性底线，须全局统一应用。
tabindex="0" 什么时候该加，什么时候不该加
加 tabindex="0" 的唯一合理场景是：这个元素视觉上可交互（比如自定义下拉触发区、手写的 tab 标签、卡片式操作区），但又不是原生可聚焦元素（button、a、input 等）。它让元素按 DOM 顺序进入 Tab 流，但仅此而已。
不该加的情况更常见：
- 纯展示文本的
div或span—— 加了只会多一个无意义的焦点停靠点 - 已用
button实现的按钮 —— 原生自带聚焦和键盘行为，加tabindex="0"属于冗余，还可能干扰 disabled 状态逻辑 - 父容器整体可操作，但子元素也单独加了
tabindex="0"—— 导致焦点重复进入，用户得按两次 Tab 才能离开同一功能区
判断依据很简单：用户 Tab 到这里后，是否「有明确且一致的操作预期」？如果没有，就别加。
键盘事件监听只绑 click 是重大遗漏
很多团队以为给自定义按钮加了 tabindex="0" 再绑个 click 就完事了。实际中键盘用户根本触发不到——他们不会“点击”，只会按 Enter 或 Space。
必须同时监听 keydown 并处理两个关键行为：
-
event.key === 'Enter'：直接触发主逻辑 -
event.key === ' '（空格）：需先event.preventDefault()阻止页面滚动，再触发逻辑
示例代码片段：
element.addEventListener('keydown', (e) => {
if (e.key === 'Enter' || e.key === ' ') {
e.preventDefault();
handleClick();
}
});
注意别用已废弃的 keyCode；也别漏掉 Space 的 preventDefault，否则用户按空格会意外滚屏。
模态框焦点锁死必须双向闭环
弹出模态框后只调一次 element.focus() 远不够。真正的焦点陷阱要解决两个问题：进得去，出得来。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
「进得去」需要：
- 打开时立刻聚焦到第一个可聚焦子元素（常用
modal.querySelector('button, input, [tabindex="0"]')） - 监听
focusin事件，捕获所有试图跳出模态框的焦点移动，并event.preventDefault()+ 强制切回内部
「出得来」容易被忽略：
- 关闭模态框前，必须记录触发它的原始元素（比如哪个按钮点开的）
- 关闭后立即调用
triggerElement.focus()，否则焦点会落到document.body或丢失
漏掉任一环，键盘用户就会卡在模态框里或关掉后彻底迷失位置。
:focus-visible 不是锦上添花，而是底线要求
直接写 outline: none 在任何可聚焦元素上，等于主动屏蔽键盘用户的焦点感知。这不是“美观问题”，是可访问性硬伤。
:focus-visible 的价值在于它自动区分触发方式：键盘聚焦时显示轮廓，鼠标点击时不显示。用法极简：
button:focus-visible,
[tabindex="0"]:focus-visible {
outline: 2px solid #0066cc;
outline-offset: 2px;
}
但要注意两点：
- 不能只给部分元素加 —— 所有可聚焦节点都应统一应用，否则会出现“有些有框、有些没框”的混乱反馈
- 别用
!important覆盖它，否则可能破坏浏览器内置逻辑
真正难的是让设计师接受「键盘焦点样式」是 UI 的一部分，而不是可以妥协的细节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
