Bootstrap 5 表单验证依赖原生 checkValidity() 和 reportValidity(),需配合 required 等属性及 is-valid/is-invalid 类同步状态;手动设 class 易错乱,应于 blur 或 submit 时根据 validity.valid 更新。

触发 bootstrap-validate 的原生验证逻辑
Bootstrap 5 自身不提供独立的表单验证库,它依赖浏览器原生 checkValidity() 和 reportValidity(),再配合 CSS 类(如 is-valid / is-invalid)做视觉反馈。所以“触发验证”本质是调用原生 API 并手动同步状态。
常见错误是直接改 class 或只设 setCustomValidity 却没调用验证方法,结果 UI 不更新、submit 仍能绕过。
- 对单个字段:先调用
input.checkValidity()判断是否通过,再调用input.reportValidity()强制显示浏览器默认提示(含 tooltip) - 对整个表单:用
form.reportValidity()—— 这会遍历所有可验证子元素并触发各自验证,同时阻止默认提交(如果任一失败) - 验证后需手动同步 Bootstrap 的 class:
input.classList.toggle('is-valid', input.checkValidity() && !input.value.trim() === false)(注意空值逻辑)
reportValidity() 在 Bootstrap 表单里为什么没反应
最常踩的坑:表单控件缺少必要属性。Bootstrap 验证样式只响应原生验证结果,但不会自动启用验证逻辑。
使用约定式提交(Conventional Commits)生成标准化的 Git 提交信息。适用于以下场景: (1) 暂存更改时需要提交信息; (2) 审查 diff 时希望获得结构化摘要; (3) 编写 PR 描述或变更日志(changelog)条目; (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff,并生成按类型(type)划分范围的提交信息。
- 确保
<input>有required、type="email"、pattern等验证属性,否则reportValidity()返回true且无提示 - 确保控件在
<form></form>内,且没有novalidate属性(它会禁用所有原生验证) - 某些自定义组件(如
bootstrap-select)不继承原生 input,需额外绑定事件或调用其自有 validate 方法
手动添加 is-valid/is-invalid 类的时机和风险
可以手动加 class,但必须与原生验证状态严格一致,否则交互错乱(比如用户已输对内容,但还显示红框)。
- 不要在输入时实时加
is-invalid;应在失去焦点(blur)或提交时,根据input.validity.valid设置 - 清空输入后,若字段为
required,应设is-invalid;若允许为空,则需调用input.setCustomValidity('')再checkValidity()来重置 - 使用
form.addEventListener('submit', e => { if (!form.checkValidity()) e.preventDefault(); })是安全的拦截方式,比单纯靠 class 更可靠
用 JS 模拟用户提交来触发完整验证流程
有时需要在非 submit 按钮点击时(比如“下一步”Tab 步骤)触发验证,又不想真的提交表单。
- 推荐写法:
const valid = form.checkValidity(); form.querySelectorAll(':invalid').forEach(el => el.reportValidity());—— 先批量检查,再对每个无效项单独报错,避免浏览器只聚焦第一个 - 避免
form.submit():它会跳过submit事件监听器,导致你写的验证逻辑失效 - 如果用了
preventDefault()后又想提交,得用fetch或XMLHttpRequest手动发数据,别试图恢复原生提交
真正麻烦的是混合了自定义校验(比如用户名是否已被占用)和原生验证——这时候得自己维护一个状态 map,reportValidity() 只管格式,业务规则得另起逻辑,别指望 Bootstrap 替你做后端联动。

















