浏览器原生表单不支持跨字段逻辑校验，需用javascript监听依赖字段变化，动态控制被控字段的required属性、setcustomvalidity()和reportvalidity()，并确保dom、validity状态、css样式和用户反馈同步更新。
多个字段间存在逻辑依赖时，不能只靠单个 required 或 pattern
比如“选择‘其他’性别时，必须填写‘原因’字段”，这种校验浏览器原生不识别——required 只响应自身是否为空，不会读取另一个 select 的值。若只给 other_reason 加 required，而没在 JS 中动态控制它的有效性，就会导致：用户没选“其他”却仍被要求填原因，或选了“其他”但字段没触发校验。
正确做法是用 JavaScript 监听依赖字段的 change 事件，在回调里手动控制被控字段的校验状态：
- 调用
other_reason.setCustomValidity("")清空旧错误（不清理会导致后续checkValidity()一直返回false） - 根据当前
gender.value判断是否应启用校验：是“other”就调用other_reason.reportValidity()触发校验，否则移除required属性并清空提示 - 别忘了在表单
submit事件中再做一次全量校验，防止用户跳过 change 直接提交
用 checkValidity() + reportValidity() 实现跨字段联动触发
原生表单的 checkValidity() 只检查单个元素，但你可以手动遍历多个字段，对每个调用它，并汇总结果。关键点在于：只有调用了 reportValidity()，浏览器才会弹出错误气泡、应用 :invalid 样式、让 form.checkValidity() 返回 false。
例如密码确认场景：
- 监听
confirm_password的input事件 - 比对
password.value !== confirm_password.value - 不等时执行
confirm_password.setCustomValidity("两次输入不一致")，相等时执行confirm_password.setCustomValidity("") - 最后必须调用
confirm_password.reportValidity()才能让错误立刻可见
漏掉 reportValidity() 是最常踩的坑——你设了错误消息，但用户看不到提示，样式也不变。
动态切换 required 属性时，要同步更新 DOM 和 validity 状态
required 是一个布尔属性，但它不是“开关即生效”。浏览器只在初始渲染或属性显式增删时重新评估该字段的必填性。如果你用 element.setAttribute("required", "") 添加，或 element.removeAttribute("required") 移除，它才真正起效。
但仅操作属性还不够：
- 移除
required后，若该字段之前因为空被标记为 invalid，它的validity.valueMissing仍为true，checkValidity()还是返回false - 所以每次切换后，都要手动调用
field.setCustomValidity("")清空自定义错误，并可选调用field.reportValidity()强制刷新 UI 状态 - 推荐封装成函数，如
toggleRequired(field, shouldRequire)，内部统一处理属性和 validity
避免用 CSS 隐藏字段替代逻辑禁用
常见错误：把“非必填字段”用 display: none 或 visibility: hidden 隐藏，以为这样就能绕过校验。实际上，隐藏的字段只要还在 DOM 里、且带 required，form.checkValidity() 依然会把它算进去，提交时照样报错。
真正安全的做法是：
- 隐藏字段时，同步
removeAttribute("required")并setCustomValidity("") - 显示时，再按规则添加
required并重置校验状态 - 或者干脆用
fieldset[disabled]包裹整组字段，disabled 字段默认不参与表单校验（但注意：disabled 字段的值不会随表单提交）
联合校验真正的复杂点不在写多少代码，而在于每一步都要同时维护 DOM 属性、JavaScript validity 状态、CSS 类名和用户可见反馈——四者不同步，就会出现“提示没弹、样式没变、但提交被拦住”这类让人摸不着头脑的问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
