Appearance
第 3 步:理解"拦截"了什么
onsubmit 处理函数 return false 时,浏览器不发这个请求——表单提交是一个事件,脚本有机会在事件默认行为发生之前介入。用 devtools 的 Network 面板验证:校验失败时根本没有产生请求。
这件事的意义超出校验本身:
- 此前几周,页面的行为都是浏览器内建的(点链接跳转、提交表单发请求)——声明式、命令式各安其位
- 从
onsubmit开始,我们接管了浏览器内建行为的决策权:什么时候放行、什么时候拦下,由代码说了算 - "注册回调、等待事件发生、决定是否放行"——这正是第 8 周事件驱动编程模型的入口
第 4 步(选做):即时校验
把校验从"提交时"提前到"输入时":给 pwd2 绑定 oninput,边输入边比对一致性,一致时把提示换成绿色 ✓。体会"事件"不止 submit 一种——blur、input、change 都是可介入的时机。
小结
| 声明式校验(第 4 周) | JS 动态校验(本实训) | |
|---|---|---|
| 规则写在 | HTML 属性 | 脚本代码 |
| 执行者 | 浏览器内建 | 自己的代码 |
| 表达力 | 单字段规则 | 多字段关联、任意逻辑 |
| 控制权 | 浏览器 | 事件回调(先声) |
- 客户端校验只是体验优化,绕过脚本即可穿透——真正的校验必须在服务端再做一次(第 4 周后端职责)