checkvalidity()方法用于检查表单或表单元素是否满足所有内置验证规则，返回布尔值，但不会触发浏览器默认的错误提示；2. reportvalidity()不仅执行验证检查，还会在验证失败时显示浏览器默认错误提示并将焦点定位到首个无效元素，适用于需要用户反馈的场景；3. 尽管reportvalidity()功能更全面，checkvalidity()仍适用于需静默验证的场合，如多步骤表单中判断是否启用下一步按钮，或配合自定义验证逻辑使用；4. 自定义错误提示可通过setcustomvalidity()设置特定错误消息，或监听invalid事件并调用preventdefault()后插入自定义dom元素来实现，从而完全控制提示内容、样式和位置；5. 浏览器默认提示虽功能完整但样式固定且体验不佳，影响整体ui美观，因此在正式产品中应采用自定义验证反馈机制以提升用户体验；6. 良好的表单验证体验应具备即时性、明确性、非侵入性和一致性，通过在用户输入过程中实时反馈具体错误信息并自然融入页面布局，可显著降低用户困惑和提交错误率，最终提升应用质量和用户满意度。
表单中的
checkValidity()
方法主要用于检查一个表单或其内部某个可验证元素（如
input
,
select
,
textarea
）是否满足了所有内置的验证规则，比如
required
、
minlength
、
max
、
type
等。它返回一个布尔值：如果所有规则都通过，则返回
true
；否则返回
false
。关键在于，它只进行检查，并不会像浏览器默认行为那样弹出错误提示框。
要手动触发表单验证并显示这些提示，通常我们会结合使用
reportValidity()
方法。
解决方案
要手动触发表单验证，你可以直接在表单元素或单个可验证元素上调用
reportValidity()
方法。这个方法不仅会执行
checkValidity()
所做的所有检查，如果验证失败，它还会触发浏览器默认的错误提示（通常是一个小气泡），并将焦点设置到第一个不合法的元素上。
例如，如果你有一个表单：
<form id="myForm"> <label for="username">用户名:</label> <input type="text" id="username" required minlength="3"> <label for="email">邮箱:</label> <input type="email" id="email" required> <button type="button" id="submitBtn">提交</button> </form>
你可以这样手动触发验证：
const myForm = document.getElementById('myForm'); const submitBtn = document.getElementById('submitBtn'); submitBtn.addEventListener('click', () => { // 调用 reportValidity() 会检查整个表单并显示错误提示 if (myForm.reportValidity()) { console.log('表单验证通过，可以提交了！'); // 这里可以执行表单提交的逻辑，比如 AJAX 请求 } else { console.log('表单验证失败，请检查输入。'); } });
如果你只想检查某个特定输入框的有效性并显示其错误：
const usernameInput = document.getElementById('username'); // ... 假设在某个事件中触发 if (!usernameInput.reportValidity()) { console.log('用户名输入不合法！'); }
为什么在
reportValidity
reportValidity
存在的情况下，我们还需要
checkValidity
？
这确实是个好问题，初看起来，
reportValidity()
似乎包含了
checkValidity()
的所有功能，并且还更“贴心”地显示了错误。但在实际开发中，
checkValidity()
有着它独特的用武之地，尤其是在那些你希望完全掌控用户体验，或者需要在幕后进行验证的场景。
我个人在工作中经常遇到这样的情况：我可能需要在一个多步骤表单中，用户完成第一步时就悄悄地检查一下输入是否符合基本要求，但我不希望立即弹出烦人的错误气泡。我只是想知道“嗯，这个数据看起来还行”，然后根据这个结果来决定是否启用下一步按钮，或者在用户离开当前字段时才显示自定义的错误信息。这时，
checkValidity()
就显得非常有用，因为它只返回一个布尔值，不产生任何副作用（比如弹出默认提示）。
再比如，你可能正在构建一个复杂的表单，它有自己的错误显示逻辑，或者你希望在用户点击“保存草稿”时，只进行一个宽松的验证，而不强制用户修正所有错误。在这些情况下，
checkValidity()
提供了一个纯粹的验证结果，让你有足够的灵活性去决定如何处理这个结果，而不是被浏览器默认的行为所束缚。它就像一个安静的顾问，告诉你事实，但把如何应对的决定权完全交给你。
如何自定义表单验证的错误提示？
虽然浏览器默认的验证提示在功能上是健全的，但它们通常样式单一，且无法很好地融入页面的整体设计。要提供更友好的用户体验，自定义错误提示是必不可少的一步。
最直接的方法是使用
setCustomValidity()
方法。这个方法允许你为可验证元素设置一个自定义的错误消息。当元素不合法时，如果你调用
reportValidity()
，浏览器就会显示你设置的这个消息。
const usernameInput = document.getElementById('username'); usernameInput.addEventListener('input', () => { // 每次输入时都清除之前的自定义错误，让浏览器重新评估 usernameInput.setCustomValidity(''); if (usernameInput.value.length < 3 && usernameInput.value.length > 0) { usernameInput.setCustomValidity('用户名至少需要3个字符哦！'); } else if (usernameInput.value.includes('admin')) { usernameInput.setCustomValidity('用户名不能包含"admin"字样。'); } // 注意：这里不会立即显示错误，需要用户提交或调用 reportValidity() }); // 当表单提交时，会显示自定义的错误提示 document.getElementById('myForm').addEventListener('submit', (event) => { if (!myForm.checkValidity()) { // 阻止默认提交，并手动触发显示错误 event.preventDefault(); myForm.reportValidity(); } });
除了
setCustomValidity()
，你还可以监听
invalid
事件。当一个可验证元素变得无效时，它会触发这个事件。你可以在这个事件处理器中阻止默认的错误提示（通过
event.preventDefault()
），然后插入你自己的错误信息到DOM中。
const emailInput = document.getElementById('email'); const emailErrorSpan = document.createElement('span'); emailErrorSpan.style.color = 'red'; emailInput.parentNode.appendChild(emailErrorSpan); // 将错误信息容器添加到输入框旁边 emailInput.addEventListener('invalid', (event) => { event.preventDefault(); // 阻止浏览器默认的错误提示 if (emailInput.validity.valueMissing) { emailErrorSpan.textContent = '邮箱是必填的哦！'; } else if (emailInput.validity.typeMismatch) { emailErrorSpan.textContent = '请检查邮箱格式是否正确。'; } // 可以根据 emailInput.validity 对象的其他属性来判断具体错误类型 }); emailInput.addEventListener('input', () => { // 当用户输入时，如果输入变得有效，就清除错误提示 if (emailInput.validity.valid) { emailErrorSpan.textContent = ''; } });
这种方法让你对错误信息的显示位置、样式和内容有完全的控制。通过检查
inputElement.validity
对象，你可以精确地知道是哪种验证失败了（例如
validity.valueMissing
、
validity.typeMismatch
、
validity.patternMismatch
等），从而给出更具体的错误提示。
表单验证与用户体验：我们真的需要那些默认的丑陋提示吗？
默认的浏览器验证提示，虽然功能上没毛病，但从用户体验（UX）的角度来看，它们往往显得有些突兀，甚至“丑陋”。它们通常是浮动的气泡，样式固定，而且在页面布局复杂时可能会遮挡内容。作为开发者，我们当然不希望用户因为这些小细节而感到困扰，或者觉得我们的应用不够专业。
在我看来，完全抛弃默认提示，转而实现一套自定义的验证反馈机制，是提升用户体验的必经之路。用户在填写表单时，最需要的是清晰、即时的反馈。一个好的验证体验应该：
- 即时性： 最好能在用户输入过程中就给出反馈，而不是等到提交时才一股脑地抛出所有错误。比如，当用户输入完一个邮箱地址后，如果格式不对，立即在输入框下方显示“邮箱格式不正确”。
- 明确性： 错误信息要具体，告诉用户哪里出了问题，以及如何修正。比如，“请输入用户名”比“字段不合法”要好得多。
- 非侵入性： 错误提示应该自然地融入页面布局，不遮挡其他内容，不打断用户操作流程。 inline（行内）错误提示通常是最佳选择，直接在受影响的输入框下方显示。
- 一致性： 无论什么类型的错误，它们的样式和显示方式都应该保持一致，让用户形成预期。
当然，这并不意味着默认提示一无是处。对于一些非常简单的内部工具或原型，它们能快速提供基础功能，省去自定义的功夫。但在面向用户的产品中，花时间打磨表单验证的UX是值得的。这不仅能减少用户的困惑和 frustration，也能有效降低错误数据提交的概率，最终提升整个应用的质量和用户满意度。毕竟，细节决定成败，而表单验证正是这些容易被忽视但又至关重要的细节之一。
评论（已关闭）
评论已关闭