在网页交互开发中，元素的视觉反馈往往依赖用户的不同操作方式。鼠标悬停产生的hover状态与键盘或脚本触发的focus状态，虽然都表示元素处于被关注的情形，但它们背后的触发源和语义并不一样。如果把这两种状态用CSS选择器合理地结合起来，就能让鼠标用户和键盘用户都获得一致且不突兀的体验。
一、hover与focus的底层差异
hover是用户通过指针设备（如鼠标、触控笔）指向元素时浏览器施加的伪类状态，它不需要元素获得文档焦点，也不影响键盘操作流。focus则是元素成为当前可交互目标时的状态，通常由Tab键遍历、点击可聚焦元素或脚本调用focus()方法产生。理解这一点很关键：一个<div>加了tabindex后可以focus，但不一定会被hover；而多数可见元素都能hover，却未必能focus。
从CSS选择器角度看，:hover和:focus都属于动态伪类。它们不会出现在DOM结构里，而是由浏览器根据用户行为实时计算。当我们在样式表中分开书写时，两种状态互不影响；若希望某元素在“被指向”或“被聚焦”时都呈现同一套样式，就需要让选择器同时命中两者。
1.1 为什么单独写会出问题
很多页面只写了a:hover { color: red; }，键盘用户用Tab移到链接上时，颜色不变，只剩默认焦点轮廓，视觉上像没反应。反之只写:focus忽略hover，鼠标用户就会觉得反馈迟钝。下面这段有缺陷的代码就是典型：
/* 有缺陷的写法：两种状态各自为战 */
.button:hover {
background: #eee;
}
.button:focus {
outline: 2px solid blue;
}
上面的代码里，hover只改背景，focus只加轮廓，鼠标悬停和键盘聚焦看到的完全是两样东西，违背了统一反馈原则。而且如果后续有人覆盖outline，键盘可用性还会悄悄丢失。
二、用选择器结合两种状态
最直接的结合方式是使用逗号选择器分组，把hover和focus放在同一条规则里。这样无论是哪种触发途径，元素都应用相同的声明块。
/* 推荐：共享视觉反馈 */
.menu-item:hover,
.menu-item:focus {
background-color: #f0f0f0;
color: #d93025;
border-radius: 4px;
}
这段代码中，逗号分隔的两个选择器权重相同，后写的不会覆盖前写，而是合并生效。鼠标移入或键盘聚焦菜单项时，背景与文字色一起变化，体验连续。要注意的是，若某些旧浏览器不完全支持:focus在普通元素上，可配合tabindex让元素可聚焦。
2.1 使用:focus-visible做精细区分
现代CSS提供了:focus-visible，它只在浏览器认为“聚焦应可见”时匹配，通常是键盘操作。我们可以让hover管鼠标，focus-visible管键盘，避免鼠标点击后留下难看的轮廓：
/* 鼠标悬停与键盘聚焦区分处理 */
.card:hover {
box-shadow: 0 2px 8px rgba(0,0,0,.15);
}
.card:focus-visible {
outline: 3px solid #1a73e8;
box-shadow: 0 2px 8px rgba(0,0,0,.15);
}
/* 普通focus去掉默认轮廓，交给visible处理 */
.card:focus:not(:focus-visible) {
outline: none;
}
这种写法兼顾了美观与无障碍。鼠标点击卡片不会闪轮廓，Tab键聚焦则明确高亮。在支持的浏览器里体验很好，不支持focus-visible的则可回退到普通focus规则。
三、实际场景中的完整示例
下面以一个横向导航和搜索输入框为例，展示hover与focus结合的综合运用。导航链接在悬停和聚焦时都有下划线和底色，输入框在聚焦时边框变色并去掉默认outline，但保留focus-visible兜底。
<nav class="top-nav"> <a href="#" class="nav-link">首页</a> <a href="#" class="nav-link">文档</a> <a href="#" class="nav-link">关于</a> </nav> <form> <label for="search">搜索</label> <input id="search" class="search-input" type="text" /> </form>
对应的样式部分如下，注意HTML标签在CSS选择器中以类命中，不直接写未转义标签：
.nav-link {
display: inline-block;
padding: 8px 12px;
text-decoration: none;
color: #333;
}
.nav-link:hover,
.nav-link:focus {
background: #e8f0fe;
color: #1a73e8;
text-decoration: underline;
}
.search-input {
border: 1px solid #ccc;
padding: 6px;
}
.search-input:focus {
outline: none;
border-color: #1a73e8;
}
.search-input:focus-visible {
outline: 2px solid #1a73e8;
}
在这个例子中，导航链接通过分组选择器统一了悬停与聚焦样式，输入框则先去掉普通focus的轮廓避免鼠标点击干扰，再用focus-visible确保键盘用户看得见焦点。两种结合策略在同一个页面里共存，互不冲突。
3.1 选择器顺序与优先级注意点
当多条规则都可能命中同一状态时，CSS优先级和源代码顺序共同决定结果。比如先写:focus { outline: none; }再写:focus-visible { outline: 2px solid; }，由于后者优先级相同且靠后，会胜出；但若把focus-visible写在前面，普通focus在后且带outline:none，键盘轮廓可能被误删。因此建议把更具体的focus-visible放在普通focus之后，或利用层叠层（@layer）管理。
| 写法 | 鼠标悬停 | 键盘聚焦 | 适用场景 |
|---|---|---|---|
| :hover, :focus 分组 | 同一样式 | 同一样式 | 简单菜单、按钮 |
| :hover + :focus-visible | 仅悬停效果 | 明确轮廓 | 注重无障碍的表单 |
| 仅:focus | 无反馈 | 有反馈 | 不推荐单独使用 |
表格里列出的三种方式，前两种都是把hover与focus做某种结合，只是粒度不同。实际项目里应根据组件角色选择：动作类按钮适合分组共享，而文本输入框更适合focus-visible区分。
四、常见误区与排查
一个容易被忽略的误区是给不可聚焦元素强行加focus样式。比如对<span>写:focus却不设tabindex，键盘用户永远触发不了，样式形同虚设。另一个误区是在hover规则里写了display:none的子菜单，但focus时没写，导致键盘聚焦后子菜单不展开，造成屏幕阅读器用户迷失。
记住：凡是鼠标hover能展开或高亮的内容，键盘focus也必须能走到同样的逻辑，否则就是可访问性漏洞。
排查时可用浏览器DevTools的“模拟hover”和“模拟focus”功能分别触发，观察Computed面板里哪些声明生效。若发现focus样式被hover覆盖，检查两者优先级与先后次序，必要时用:focus显式提升或改用focus-visible。
4.1 与JavaScript的配合
有时元素默认无法focus，需要用脚本补tabindex，或在自定义组件里手动管理焦点。此时CSS的hover与focus结合依然有效，只要元素真的获得了焦点状态。例如用下面脚本让弹层可聚焦：
// 让自定义弹层支持键盘聚焦
const panel = document.querySelector('.popup');
panel.setAttribute('tabindex', '-1');
panel.focus();
加上这段后，.popup:focus或.popup:focus-visible就能正常响应，与hover规则结合也不会落空。总体来看，CSS选择器处理hover与focus的结合并不复杂，难在一致地贯彻到每个交互组件，并留意旧版浏览器的回退方案。