失焦后校验是较稳妥的时机
别名: 失焦校验 · on blur · validate on exit · field-level validation
概念解释
失焦校验在字段失去焦点时跑规则：人按 Tab、点下一字段、或点到字段外的空白，等于宣布「这项我填完了」。此时才显示格式或必填错误，中间态不会被当成终态。它比逐键报错稳，也比只在整表提交时才说话更早。这条谈的是「何时做第一次判定」，不解释逐键为什么伤人，也不规定已经变红的字段在改正过程中要不要立刻熄火。提交失败后焦点去哪、顶部清单一不算不算数，是定位与汇总，不是失焦本身。
机制
焦点离开是人给出的完成信号。校验器这时面对的接近终态：邮箱该有 @，日期该是一整段。把判定绑在这个信号上，错误针对的是人以为已经交出去的值，而不是正在敲的前缀。第二层是节奏：填表是「写 → 换项 → 写」。失焦校验把反馈插入换项这一拍，不插入击键这一拍，运动程序得以完整。只在提交时校验则把所有错误堆到终点，人要沿整张表回溯。失焦的稳妥来自「完成信号 × 就地反馈」，不是来自失焦这个 DOM 事件本身——若系统在自动补全结束前抢跑失焦，或移动端「下一步」并不触发 web 的 blur，这个信号就没发出去。
怎么研究
比较三种第一次报错时机：逐键、失焦、仅提交。字段集合里要包含会跨项粘贴的值（从密码管理器填入邮箱再 Tab）。
自变量：第一次错误的触发事件（input / blur / submit）、移动端是否用「下一步」而不是 blur、自动填充是否在校验前完成。 因变量：该项上的无效中间态错误次数、从错误出现到改正的时间、提交时仍未看过的错误数、误报（值尚未完成就被判错）次数。
实验室用鼠标点下一字段，blur 很干净；触屏和键盘用户的离开路径不同，必须分开测。不要把「失焦组完成更快」直接归因于时机——若该组同时还改了文案位置，变量缠在一起。
边界
最后一项常常用回车或主按钮提交，焦点可能从未离开该字段，失焦校验一次都不会跑；提交校验必须作为兜底，否则最后一项是盲区。自定义下拉、日期面板在选择过程中可能反复 blur/focus，把选择动作打成多次「完成」。禁用 JavaScript 或校验全在服务端的表单没有失焦这层。跨字段约束（两次密码、起止日期）不能在第一次失焦时定论，因为另一半还不存在。
怎么落地
- 把字段级格式与必填的第一次提示绑在真正的完成信号上：blur、移动端工具栏的「下一步」、或选择器确认，而不是每个字符。
- 整表提交时再跑一遍同样的规则，覆盖从未失焦的最后一项和脚本没能收到 blur 的控件。
- 对会在面板内多次失焦的日期、下拉，等到面板关闭或选项确认后再判，不要在打开面板的瞬间报「必填」。
- 验证：只填到最后一项就点提交，确认最后一项的错误仍出现。再用键盘 Tab 走过邮箱，确认错误出现在离开之后而不是第一个字符。在真机键盘工具栏按「下一项」，确认校验有跑。自动填充整段邮箱后，错误不得在值写完前闪一次。