form.submit()不触发原生验证，因其绕过浏览器校验流程；正确方式是用form.requestsubmit()或type="submit"按钮触发，才能激活required、pattern等验证。
为什么 form.submit() 不触发原生验证
直接调用 form.submit() 会绕过浏览器内置的验证流程，导致 required、pattern 等属性完全失效——这是最常被忽略的底层机制差异。
原生验证只在用户主动触发提交行为时激活：比如点击 <button type="submit"></button>、按回车（且焦点在可提交表单内）、或调用 form.requestSubmit()。后者才是 JS 主动触发验证的正确入口。
-
form.requestSubmit()会触发invalid事件、检查 validity 状态、显示默认提示，并在全部通过后才真正提交 -
form.submit()是纯 DOM 提交，跳过所有约束验证逻辑，等同于后端直连 - 若用
<button></button>未显式设type="submit"，点击也不会触发验证（默认是type="button"）
如何拦截并定制 invalid 事件提示
浏览器默认的 tooltip 或 alert 式提示无法样式化，且不支持动态内容。要接管错误反馈，必须监听 invalid 事件并在捕获阶段阻止默认行为。
关键点在于：必须用 addEventListener('invalid', handler, true)（第三个参数为 true 表示捕获阶段），否则事件已冒泡完成，preventDefault 失效。
- 在 handler 中调用
event.preventDefault()阻止默认弹窗 - 用
input.setCustomValidity('自定义错误信息')设置提示文本 - 后续用户输入时，需手动调用
input.setCustomValidity('')清空，否则 validity 始终为 false - 推荐在
input或blur事件中做即时重校验，避免错误状态滞留
pattern 正则匹配失败的常见陷阱
pattern 属性对正则有隐式全匹配要求（自动包裹 ^ 和 $），但实际使用中极易因边界、空格或 Unicode 处理不当而误判。
它只对 type="text"、type="email" 等字符串类输入生效，对 type="number" 或 type="date" 完全无效——这些类型走的是各自独立的解析逻辑。
- 手机号别写
pattern="\d{11}"，应写pattern="^1[3-9]\d{9}$"并配title="请输入11位手机号" - 中文匹配慎用
\u4E00-\u9FA5，部分浏览器解析异常；改用[\u4e00-\u9fa5]（无反斜杠转义）更稳妥 -
pattern不校验空值——空由required控制，二者必须共存才能覆盖完整校验场景
required 提示不出现的隐藏原因
加了 required 却没反应，往往不是属性没写对，而是验证时机或 DOM 状态被干扰。
常见干扰源包括：CSS 隐藏（display: none 或 visibility: hidden）、自定义封装组件未透传原生属性、表单结构嵌套错误（如 form 内含另一个 form）、或 input 被禁用（disabled 状态下 required 会被忽略）。
- 未交互过的
required字段初始为:valid，直到首次失去焦点或提交才变为:invalid - 用
:valid/:invalid伪类控制样式时，需配合:user-invalid（Chrome 支持）或 JS 判断input.validity.valid才能精准响应 - 移动端键盘类型适配依赖
type属性，比如type="tel"才能唤起数字键盘，required单独存在无法触发该行为
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
