结论：不建议在 :hover 中无条件使用 @keyframes 抖动动画，因其缺乏语义、易引发卡顿与无障碍风险；仅当作为明确交互反馈（如表单校验失败）时，配合 JS 控制、视觉锚点和合理节奏才有效。
直接说结论：用 @keyframes 做悬停抖动，容易变成干扰项，除非你明确它服务于具体交互意图（比如表单校验失败），否则不建议在 :hover 里无条件触发。
为什么 :hover 抖动常被误用
抖动本身没有语义，用户鼠标一划就抖，既不表示可点击，也不提示错误，反而破坏预期。浏览器渲染时频繁触发 transform 和 rotate 还可能引发轻微卡顿（尤其低端设备）。
- 抖动动画通常包含 8–12 帧位移+旋转组合，
animation-timing-function若用linear会显得机械；用ease-out收尾更自然 -
:hover是瞬态伪类，用户稍一偏移就中断动画，导致抖到一半戛然而止，观感突兀 - 无障碍场景下，持续抖动可能触发光敏性癫痫警告（WCAG 2.3.3 要求避免闪烁超过 3 次/秒）
@keyframes shake 的关键帧怎么写才不假
真抖不是来回平移，得有“惯性感”：起始微偏、中间反向过冲、末尾回弹衰减。下面这段是经过多次调试的常用基线：
@keyframes shake {
0% { transform: translate(0, 0); }
25% { transform: translate(-4px, 0); }
50% { transform: translate(2px, -2px); }
75% { transform: translate(-2px, 2px); }
100% { transform: translate(0, 0); }
}
- 别用纯对称位移（如 ±5px 循环），人眼会识别为机械振动，失去“受力反馈”感
- 旋转角度控制在 ±1deg 内，超过 2deg 就像按钮要散架，而非轻微震动
- 总时长建议 ≤ 0.5s，再长就从“提示”滑向“骚扰”
什么时候该用 JS 控制抖动，而不是 :hover
抖动真正有用的地方，是作为状态反馈——比如输入校验失败、API 请求超时、权限不足等明确事件发生后。
立即学习“前端免费学习笔记（深入）”；
- 给元素加
shake类，比写.btn:hover { animation: shake 0.5s; }更可控 - JS 中加完类后，用
setTimeout清除，避免连续抖动堆积（特别是快速反复触发时） - 配套视觉锚点很重要：抖动同时让边框变红、图标加叹号，否则抖了等于白抖
- 移动端慎用：触摸无 hover，且手指悬停区域难判定，优先用 toast 或 inline 文案提示
真正难的从来不是写出抖动动画，而是判断它出现的时机、持续的节奏、以及收尾后是否留下可理解的状态痕迹。没想清这三点，代码再酷也只是动效噪音。
