原生表单校验可通过属性叠加与Constraint Validation API协同实现多重条件组合验证。关键在于分层落实基础约束，并用JavaScript补足字段间关联逻辑，如动态切换required、监听事件比对、调用checkValidity和setCustomValidity等，同时必须配合后端校验确保安全性。
原生表单校验本身不直接支持“多重条件组合”的逻辑判断（比如“选A时必须填B且B不能等于C”），但它能通过属性叠加 + Constraint Validation API 协同实现复合验证效果。关键不是靠单个属性，而是把基础约束分层落实，再用 JavaScript 补足关联逻辑。
用 required + type + pattern 组合覆盖常见复合前提
很多所谓“复合条件”，其实可拆解为多个独立但有先后依赖的校验点。浏览器会按顺序检查：是否为空 → 类型是否匹配 → 格式是否合规 → 范围是否越界。
- 例如手机号+区号联合校验：可将区号设为 select，手机号 input 加 pattern="^1[3-9]\d{9}$"，并用 required 控制“选了区号就必须填手机号”；若区号未选，则手机号 input 不加 required，自然跳过校验。
- 例如邮箱必填但仅在勾选“接收通知”时才启用：给邮箱 input 动态添加或移除 required 属性（注意：不能只靠 display:none 隐藏，要真正 toggle required），再配合 setCustomValidity 清空/设置错误。
- 密码强度+确认一致性：密码字段用 pattern 和 minlength 保证基础强度；确认密码字段不设 pattern，但监听 input 事件，比对值是否相等，不等则 this.setCustomValidity("两次输入不一致")。
用 checkValidity() + 自定义事件触发全量联动校验
当一个字段的校验结果依赖其他字段状态时，不能只靠单个 input 的事件，而要在关键节点主动调用 checkValidity() 并干预整个表单状态。
- 在“提交”按钮点击或表单 submit 事件中，先遍历所有相关字段，手动执行校验逻辑（如：如果 gender 是 "other"，则 other_reason 必须非空）。
- 对触发条件字段（如开关、下拉框）绑定 change 事件，在回调里对被控字段调用 setCustomValidity() 和 reportValidity()，让错误立刻可见。
- 避免只改样式或提示文字——必须调用 setCustomValidity("") 清空旧错误，否则 checkValidity() 会持续返回 false。
用 CSS :valid/:invalid + JS 状态同步提升反馈一致性
原生校验的视觉反馈有限，但 :valid/:invalid 伪类能自动响应 valid/invalid 状态。结合 JS 可让多字段联动更直观。
- 给关联字段组加统一 class（如 .group-password），当任一字段 invalid 时，用 JS 给整个 group 添加 .has-error 类，统一高亮或显示提示区。
- 利用 validity 对象的各布尔属性（如 validity.valueMissing、validity.patternMismatch、validity.customError）做精细化判断，而不是只看 validity.valid。
- 不要覆盖默认气泡提示，除非你完整实现了 ARIA-live + 键盘焦点管理——原生气泡已适配读屏器和移动端交互。
后端校验不可省，原生只是第一道筛子
所有前端复合验证都可能被绕过。比如用户禁用 JS、手动修改 DOM、或用 curl 提交。原生校验的目标是拦截明显错误、减少无效请求、提升填写体验，而非替代服务端逻辑。
- 用户名是否已被注册、优惠码是否有效、支付金额是否超限——这些必须由后端返回明确结果，并在前端用 setCustomValidity() 注入对应提示。
- 提交失败后，后端应返回结构化错误字段（如 { "field": "email", "message": "该邮箱已被注册" }），前端据此定位 input 并设置错误。
- 保持前后端正则一致（如手机号 pattern），避免前端放过、后端拒收，造成体验断层。
