17370845950

JavaScript表单验证需手写逻辑+合理触发时机+可访问性支持，禁用原生属性糊弄；监听submit事件拦截所有提交方式；trim后校验、内嵌错误提示、服务端必须重复验证。

JavaScript 表单验证不能只靠 required 或 pattern 属性糊弄，浏览器原生校验太浅，交互差，且无法覆盖业务逻辑（比如“密码和确认密码必须一致”“用户名已被注册”）。真要可靠，得手写验证逻辑 + 合理触发时机 + 可访问性支持。

用 addEventListener('submit') 拦截表单提交，而不是监听 click 按钮

监听 submit 事件才能捕获所有提交方式：回车、按钮点击、甚至 form.submit() 调用。监听按钮容易漏掉回车提交，还可能因多个提交按钮而逻辑混乱。

• 务必在回调里调用 event.preventDefault()，否则表单会直接提交并刷新页面
• 验证失败后，聚焦第一个出错的 （用 element.focus()），这对键盘用户很关键
• 不要只依赖 input.value.length 判空——要 trim 后判断，否则空格会绕过校验

document.querySelector('form').addEventListener('submit', function (e) {
  e.preventDefault();
  const email = this.querySelector('[name="email"]').value.trim();
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    alert('邮箱格式不正确');
    this.querySelector('[name="email"]').focus();
    return;
  }
  this.submit(); // 验证通过才真正提交
});

避免用 alert() 或 console.log() 做错误提示

弹窗打断操作流，console.log() 对普通用户完全不可见。错误信息必须内嵌在 DOM 中，紧邻对应字段，并用 aria-live="polite" 支持屏幕阅读器。

• 每个输入框配一个
• 验证失败时填入文本，并加 aria-invalid="true" 到 input 上
• 成功后清空错误提示，同时移除 aria-invalid 和错误 class
• 别用 display: none 隐藏错误提示——屏幕阅读器会跳过；改用 visibility: hidden 或 opacity: 0 + position: absolute

服务端验证不可省略，前端只是体验层

前端验证能提升响应速度和用户体验，但所有校验逻辑（尤其是涉及权限、唯一性、金额、状态）必须在服务端重复执行。攻击者可以禁用 JS、绕过前端、直接发请求。

立即学习“Java免费学习笔记（深入）”；

• 例如邮箱唯一性：前端只能查本地缓存或发个预检请求（fetch('/api/check-email?email=xxx'），但最终注册接口仍需服务端再查一次数据库
• 密码强度规则（如“至少1个大写字母+1个数字”）前后端正则必须严格一致，否则用户在前端看到“符合”，提交后服务端报错，体验极差
• 服务端返回的错误字段名应与前端 DOM 的 name 或 id 对齐，方便统一映射显示

复杂规则建议封装成可复用的验证函数，而非散落各处

把验证逻辑抽成纯函数，比如 validateEmail(value)、validatePasswordMatch(pwd, confirm)，既方便单元测试，也利于后续接入表单库（如 React Hook Form）。

• 函数应只做一件事：接收值，返回 { valid: boolean, message?: string }
• 避免在验证函数里操作 DOM 或发请求——那是调用方的责任
• 对异步验证（如用户名是否可用），返回 Promise，并在 UI 上加 loading 状态
• 注意正则中的 ^ 和 $：没它们的话，/abc/.test('xabcx') 也会返回 true，导致误判

最常被忽略的是验证时机：只在提交时校验不够。应该在用户离开字段（blur）时做基础格式检查，在输入过程中（input）做实时反馈（如密码强度条），但避免每敲一个字都发请求或弹错。平衡性能、体验和可访问性，才是难点所在。