input事件是最适合作为实时校验触发点的方案，它在每次输入（含粘贴、删除、中文上屏）时触发，兼顾实时性与体验，且需避开keyup陷阱、合理使用css类名控制反馈、区分异步校验状态、保留focus/blur以支持无障碍。
input事件监听比blur更适合作为实时校验触发点
用户还没输完就报错，体验差；等失焦才校验，又不够“实时”。真正平衡的方案是用 input 事件——它在每次输入（包括粘贴、删除、中文输入法上屏后）都触发，且现代浏览器兼容性已无顾虑。
注意避开两个坑：
一是别用 keyup，它捕获不到鼠标粘贴、右键粘贴、拖入文本等操作；
二是中文输入法下，input 在“上屏完成”后才触发，符合预期，无需额外防抖处理拼音未上屏的误判。
实操建议：
• 对每个需校验的 <input> 绑定 addEventListener('input', handler)
• handler 中直接读取 event.target.value，不要依赖 change 或定时器
• 避免在 handler 里调用耗时操作（如接口请求），复杂逻辑建议节流或延迟 300ms
校验状态应通过CSS类名而非内联样式控制反馈样式
把校验结果映射到元素的 class 上，比如 is-valid、is-invalid、is-pending，再由 CSS 控制边框颜色、图标、提示文字显隐。这样结构清晰，也方便后续换主题或加动画。
常见错误是直接改 style.borderColor 或 innerHTML，导致样式耦合、难以维护、无法做过渡动画。
实操建议：
• 输入框父容器（如 <div class="form-control">）统一管理状态类，避免污染 input 自身<br>• 错误提示文案用独立 <code><div class="invalid-feedback">，默认 <code>display: none，仅当有 is-invalid 类时显示
• 使用 element.classList.toggle('is-invalid', !isValid) 切换状态，比手动增删更安全
异步校验（如用户名唯一性）必须区分“校验中”和“校验失败”状态
用户输完立刻发请求，但网络有延迟。如果只在成功/失败后更新 UI，中间空白期会让人困惑：“到底有没有在检查？”
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
关键不是“能不能做”，而是“怎么让用户感知进度”。纯前端正则校验可同步执行，但涉及服务端的，必须暴露中间态。
实操建议：
• 提交前禁用提交按钮，或添加 data-loading 属性配合 CSS 禁用态
• 异步开始时立即添加 is-pending 类，显示加载图标或灰化提示
• 接口返回后，移除 is-pending，再根据结果添加 is-valid 或 is-invalid
• 错误提示文案要具体，比如 “该用户名已被注册”，而不是 “校验失败”
focus/blur 仍需保留，用于聚焦引导与无障碍支持
光靠 input 事件不能替代 focus 和 blur。前者负责“内容变化”，后者负责“交互意图”：用户刚点进来时，可能需要清空 placeholder 提示；离开字段时，即使没改动，也该做一次终审（比如邮箱格式最后确认）。
更重要的是，屏幕阅读器依赖 focus 顺序和 aria-invalid 属性播报错误，纯 input 事件无法满足 WCAG 要求。
实操建议：
• focus 时移除 is-invalid（清空旧错误，避免干扰当前输入）
• blur 时强制执行一次完整校验，尤其对未触发过 input 的空字段
• 动态设置 aria-invalid="true" 和 aria-describedby 指向错误文案 ID
• 不要用 title 属性做错误提示——它不被所有读屏器识别，且会覆盖原生 tooltip
最易被忽略的是多字段联动校验场景：比如“确认密码”必须等“新密码”非空且有效后才开始校验。这类逻辑不在单个 input 的事件里，得靠字段间状态订阅或集中式表单管理，硬塞进每个 input 的 handler 里只会让代码不可维护。
