必须监听 form 的 submit 事件并在回调首行同步调用 e.preventDefault()，否则回车、submit 按钮或 JS 调用 form.submit() 均会绕过验证直接提交；异步校验（如用户名是否存在）不可用于 submit 回调，仅支持同步客户端规则；按钮务必显式设置 type="button"（非交互场景）或确保 type="submit" 时 preventDefault 严格前置；禁用内联 onsubmit="return false"，以免阻断事件流与框架集成。
必须监听 form 元素的 submit 事件，并在回调第一行同步调用 e.preventDefault()，否则验证逻辑再完整也拦不住提交。
为什么只绑按钮 click 会失效
表单的默认刷新/跳转行为只由 submit 事件触发，click 事件本身没有这个默认行为。用户按回车、点击 <button type="submit">、甚至 JS 调用 form.submit()，最终都会派发 submit 事件——但不会都触发按钮的 click。
常见错误现象：
- 输入后按回车，页面刷新，控制台没报错，JS 根本没执行
- 按钮绑了
onclick并return false，但回车照样提交 - 表单里有多个提交入口（按钮 + 回车 + 动态插入的按钮），只拦了一个
正确做法：所有提交路径统一收口到 form.addEventListener('submit', ...)，一劳永逸。
立即学习“前端免费学习笔记（深入）”；
验证必须同步完成，不能等异步结果
submit 事件无法暂停等待 API 响应。像“用户名是否已存在”这类需服务端校验的逻辑，不能放在 submit 回调里异步判断后决定是否放行——你调用 fetch 的那一刻，浏览器早已开始提交或刷新了。
适用场景仅限纯客户端可判定的规则：
- 必填字段是否为空（检查
input.value.trim() === ''） - 邮箱格式（用
/^\S+@\S+\.\S+$/测试） - 密码长度与一致性（对比
password和confirmPassword） - 手机号是否符合国内 11 位数字模式
验证失败时，建议立刻聚焦首个错误字段：form.elements.email.focus()，别等 DOM 更新完再操作，避免焦点丢失。
按钮 type 属性不显式声明，就等于埋雷
<button>提交</button> 在 form 内部默认就是 type="submit"。哪怕你 JS 已绑定好 submit 监听器，只要执行稍慢、出错或 DOM 尚未就绪，它就会直接触发原生提交。
稳妥方案分两类：
- 纯前端交互（如搜索、筛选、主题切换）：用
<button type="button">提交</button>，从源头切断提交 - 语义明确的业务表单（如登录、注册）：仍用
type="submit"，但确保submit回调第一行就是e.preventDefault()
动态插入按钮时尤其注意：不写 type，等于默认 submit，极易漏检。
内联 onsubmit="return false" 看似简单，实则危险
这种写法能拦住默认行为，但会彻底中断事件流：onsubmit="return false" 会让后续所有通过 addEventListener 绑定的 submit 监听器失效——调试时加的 log 不会打印，框架注入的校验也不会运行。
更隐蔽的问题：
- 无法在拦截后执行异步逻辑（比如发
fetch） - 和 Vue/React 等框架的合成事件机制冲突，容易出现“有时生效有时不生效”
- 违反渐进增强原则，可访问性工具可能无法正确识别表单状态
真正需要调试时，最有效的确认方式是：在 submit 回调开头加 console.log('submit fired')，再加 console.log(e.isDefaultPrevented())，看是否真被阻止——而不是靠“没跳转”来反推。
