JavaScript表单验证需手写逻辑+合理触发时机+可访问性支持，禁用原生属性糊弄；监听submit事件拦截所有提交方式；trim后校验、内嵌错误提示、服务端必须重复验证。
JavaScript 表单验证不能只靠 required 或 pattern 属性糊弄，浏览器原生校验太浅，交互差，且无法覆盖业务逻辑（比如“密码和确认密码必须一致”“用户名已被注册”）。真要可靠，得手写验证逻辑 + 合理触发时机 + 可访问性支持。
用 addEventListener('submit') 拦截表单提交，而不是监听 click 按钮
监听 submit 事件才能捕获所有提交方式：回车、按钮点击、甚至 form.submit() 调用。监听按钮容易漏掉回车提交，还可能因多个提交按钮而逻辑混乱。
- 务必在回调里调用
event.preventDefault()，否则表单会直接提交并刷新页面 - 验证失败后，聚焦第一个出错的
<input>（用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" 支持屏幕阅读器。
- 每个输入框配一个
<span class="error" aria-live="polite"></span> - 验证失败时填入文本，并加
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<{ valid: boolean, message?: string }>，并在 UI 上加 loading 状态 - 注意正则中的
^和$：没它们的话，/abc/.test('xabcx')也会返回true，导致误判
最常被忽略的是验证时机：只在提交时校验不够。应该在用户离开字段（blur）时做基础格式检查，在输入过程中（input）做实时反馈（如密码强度条），但避免每敲一个字都发请求或弹错。平衡性能、体验和可访问性，才是难点所在。
