tabindex 与 focus-within 是协作关系：tabindex 决定元素能否被键盘聚焦，focus-within 监听其内部任意子元素获得焦点；若父容器无 tabindex 且无可聚焦子元素，则 focus-within 不触发。
tabindex 和 focus-within 的关系不是替代，而是协作
直接用 focus-within 无法“实现” tabindex 的功能——tabindex 决定元素能否被键盘聚焦，focus-within 只是监听其内部任意子元素获得焦点。如果父容器本身没设 tabindex，且内部没有可聚焦子元素（比如全是 <div>、<p>），那 focus-within 根本不会触发。
所以关键不是“用 CSS 替代 tabindex”，而是：先让容器或其子元素可聚焦，再用 focus-within 做样式响应。
- 若想整个容器能被 Tab 键聚焦并高亮自身，需给容器设
tabindex="0"（不推荐盲目加，会破坏语义和屏幕阅读器体验） - 更合理的方式是确保容器内有天然可聚焦元素（如
<button>、<a href>、带tabindex="0"的<div>），然后对容器写:focus-within -
tabindex="-1"允许 JS 主动聚焦（el.focus()），但不能通过 Tab 键进入；这种场景下focus-within仍有效
focus-within 触发的常见失效原因
写好 .container:focus-within { background: yellow; } 却没反应？大概率卡在这几个点：
- 父容器没设置
display或被overflow: hidden截断，导致焦点状态无法冒泡（focus-within依赖焦点事件冒泡机制） - 子元素用了
outline: none且没提供其他视觉反馈，你以为没聚焦，其实已聚焦但看不见 - 子元素是
contenteditable="true"的<div>，它默认可聚焦，但某些浏览器需显式加tabindex="0"才稳定触发focus-within - CSS 优先级问题：父容器的背景色被更具体的规则覆盖，检查 computed styles 确认
focus-within是否匹配成功
实际可用的最小可运行组合
以下 HTML + CSS 能稳定触发父容器高亮，无需 JS：
立即学习“前端免费学习笔记（深入）”；
<div class="card">
<h3>操作区</h3>
<button>确认</button>
<button>取消</button>
</div>
.card:focus-within {
border: 2px solid #007bff;
box-shadow: 0 0 8px rgba(0,123,255,.25);
}
注意：<button> 天然可聚焦，Tab 切换到任一按钮时，.card 就会应用样式。不需要给 <div class="card"> 加 tabindex。
- 如果按钮被
disabled，它不可聚焦，focus-within不会触发——得确保至少一个子元素处于可聚焦状态 - 若用
<span tabindex="0">点击编辑</span>替代按钮，同样生效，但要加cursor: pointer和键盘交互逻辑（Enter/Space 触发） - Firefox 61+、Chrome 65+、Safari 15.4+ 支持
focus-within；旧版 Safari 需用 JS 模拟
别忽略的可访问性细节
仅靠 focus-within 实现视觉高亮，容易漏掉两个关键问题：
- 键盘用户看不到焦点落在哪个具体子元素上——必须保留或重置
outline，或用box-shadow+outline: none配合focus-visible（避免鼠标用户看到冗余轮廓） - 如果父容器内容动态加载（比如异步插入按钮），新插入的可聚焦元素不会自动“激活”
focus-within，除非已有焦点在容器内；首次加载后需手动聚焦某个子元素，或等用户 Tab 进入 - 嵌套容器时，外层
focus-within会因内层任意子元素聚焦而触发——这不是 bug，是设计如此；如需精确控制，得用 JS 监听focusin并判断event.target是否属于预期子集
真正麻烦的从来不是写对一行 CSS，而是让焦点路径清晰、可预测、不打断用户流。
