input:invalid 晃不动是因为该伪类仅在失去焦点或表单提交时，且存在 required/pattern 等原生验证属性被违反才生效；不响应 setCustomValidity() 除非手动调用 reportValidity() 或 checkValidity() 后 blur。
输入框错误时摇晃，必须用 transform: translateX() + @keyframes，不能靠 margin 或 left——否则触发重排，低端设备一卡一卡，用户还没看清提示就卡住了。
为什么 input:invalid 晃不动？
HTML5 的 :invalid 伪类只在表单验证规则（如 required、pattern、type="email"）被违反且元素失去焦点（blur）或表单提交时才生效。它不会响应 JS 主动设置的 setCustomValidity() 错误，除非你手动调用 reportValidity() 或触发一次 checkValidity() 后再 blur。
- 没加
required或pattern属性 →:invalid永远不匹配 - 用户还没输完就点了提交 → 此时可能仍为
:valid，需用 JS 主动校验 - 用了
inputmode="numeric"但没配pattern="[0-9]*"→ 移动端键盘不触发原生校验逻辑
shake 动画类怎么写才不翻车？
关键不是“动起来”，而是动得干净、可控、不溢出。下面这段是经过多端实测的最小可靠写法：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
@keyframes shake {
0%, 100% { transform: translateX(0); }
25% { transform: translateX(-8px); }
50% { transform: translateX(0); }
75% { transform: translateX(8px); }
}
.shake {
animation: shake 0.4s ease-in-out 1;
animation-fill-mode: forwards;
}
- 位移量固定 ±8px：太小（±2px）用户无感，太大（±15px）像抽搐
- 时长 0.4s：比 0.5s 更“脆”，符合错误反馈的瞬时性
- 必须加
animation-fill-mode: forwards，否则动画结束瞬间跳回原位，视觉断裂 - 别加
infinite—— 错误提示不是 Loading，持续晃会干扰操作
JS 触发晃动时，哪些细节决定体验？
纯 CSS 能做基础反馈，但真实场景中往往要配合 JS 控制时机和清理状态。常见坑点：
立即学习“前端免费学习笔记（深入）”；
- 重复点击提交按钮 → 多次添加
shake类 → 动画叠加卡顿；应先element.classList.remove('shake')再add - 晃动期间用户继续输入 → 需监听
input事件并立刻移除shake类，避免“边输边晃” - 移动端 Safari 对
transform动画有合成层限制 → 加will-change: transform提前升层，但仅对目标元素加，别全局滥用 - 晃动时禁用交互更安全 → 可临时设
pointer-events: none，动画结束再恢复
最易被忽略的是：晃动必须和语义化错误提示同步。光抖没文字，用户不知道错在哪；有文字不抖，反馈力度不够。两者缺一不可，且动画结束时间要和提示显示/隐藏节奏对齐——否则用户眼睛在追动画，根本没读提示。
