HTML表单校验顺序为：空值→required→pattern→step，导致required与pattern冲突；应移除原生属性，用setCustomValidity配合reportValidity统一控制，并确保服务端重复校验。
HTML required 和自定义校验规则冲突的典型表现
当你给一个 <input> 同时加了 required 属性和 pattern（比如 pattern="[0-9]{6}"），用户只输入 5 位数字时，浏览器会先触发 required 的“非空”校验，报错“请填写此字段”，而根本不会走到 pattern 校验。这不是 bug，是 HTML 表单校验的默认顺序：空值 → required → pattern → step 等。
用 value="" + checkValidity() 手动控制校验时机
绕过原生校验顺序的最直接方式，是把 required 去掉，改用 JS 主动触发校验。关键点在于：清空值时保留 value=""（而非移除 value 属性），否则 checkValidity() 可能返回 true（尤其在某些 Safari 版本中）。
实操建议：
- 移除所有
required、pattern、minlength等原生属性，统一交由 JS 控制 - 提交前调用
form.checkValidity()，它会按 DOM 顺序检查每个字段的validity对象 - 对每个字段单独校验时，用
input.reportValidity()触发带提示的 UI 校验（兼容性 OK，Chrome 53+/Firefox 53+/Edge 79+） - 若需支持老版本 Edge 或 IE，改用
input.setCustomValidity("错误信息")+input.reportValidity()组合
setCustomValidity("") 清空状态比 removeAttribute("required") 更可靠
很多人试图动态增删 required 属性来切换必填逻辑，但这样容易导致 validity.valueMissing 状态残留或不更新。真正干净的做法是：无论是否必填，都保持 required 移除，靠 setCustomValidity() 控制校验结果。
立即学习“前端免费学习笔记（深入）”；
示例逻辑：
input.addEventListener("input", () => {
if (shouldRequired && !input.value.trim()) {
input.setCustomValidity("此项为必填");
} else if (shouldRequired && !/^[0-9]{6}$/.test(input.value)) {
input.setCustomValidity("请输入6位数字");
} else {
input.setCustomValidity(""); // 关键：必须显式清空，否则状态一直为 invalid
}
});
注意：setCustomValidity("") 不等于没调用——它代表“校验通过”，缺了这句，后续任何 reportValidity() 都会沿用上一次的错误信息。
服务端永远要重复校验，前端只是体验层
所有前端校验（包括 required、pattern、JS 手动 setCustomValidity）都可被绕过。比如用户禁用 JS、用 curl 提交、或直接修改 DOM。所以服务端收到数据后，必须重新执行完整校验逻辑，且错误信息应与前端一致，避免用户困惑。
容易被忽略的一点：前后端正则表达式行为可能不同。例如前端用 /^[0-9]{6}$/，后端 Python 用 re.match(r"^[0-9]{6}$", s) 是等价的，但若写成 re.search(r"[0-9]{6}", s) 就会漏掉长度校验——这种细节差异在线上常引发“前端校验通过、后端报错”的问题。
