最直接禁用HTML表单原生验证的方法是使用formnovalidate属性控制特定提交按钮，或在form标签添加novalidate属性全局禁用；前者适用于同一表单中部分提交需跳过验证（如保存草稿），后者用于完全由JavaScript或服务器处理验证的场景，两者均将验证控制权交予开发者，但必须配合JavaScript实现客户端验证和服务器端安全校验以确保数据完整性与安全性。
在HTML表单中禁用原生验证，最直接的方式是使用
formnovalidate属性加在提交按钮上，或者在
在这个例子里，点击第一个“提交表单”按钮时，浏览器会检查“用户名”和“邮箱”字段是否符合
required和
type="email"的验证规则。但点击“保存草稿”按钮时，即使字段为空或格式不正确，表单也会直接提交，跳过客户端的验证提示。我个人觉得这种细粒度的控制在很多业务场景下非常实用，尤其当一个表单承载了多种操作路径时。
方法二：禁用整个表单的验证
如果你决定完全由JavaScript或服务器端来接管表单的验证逻辑，那么直接在
有了
novalidate属性，无论用户如何尝试提交，浏览器都不会弹出任何关于“必填项”或“数字范围”的验证提示。这给我一种感觉，就是开发者明确地告诉浏览器：“嘿，这块我来搞定，你不用操心了。”
什么时候应该禁用HTML表单验证？
禁用HTML表单原生验证并非是对数据质量的放弃，而是一种策略选择。在我看来，这通常发生在以下几种情况，它们往往要求我们拥有更精细、更灵活的控制力：
一个很常见的场景是自定义JavaScript验证。HTML5的内置验证虽然方便，但功能相对基础。比如，它无法验证密码强度（需要包含大小写字母、数字和特殊字符），也无法进行跨字段验证（例如，“确认密码”必须与“新密码”一致），更别提复杂的业务逻辑验证了。当我们使用JavaScript框架（如React, Vue, Angular）或纯JS来构建更丰富、实时反馈的验证逻辑时，原生验证的提示反而可能与我们自定义的UI体验冲突，甚至显得多余。我常常觉得，原生的提示框虽然直接，但有时不够美观，也难以集成到我们精心设计的错误提示系统中。
保存草稿或部分数据也是一个重要的考虑点。设想一个用户正在填写一份长表单，他可能只想保存当前已填写的部分，以便稍后继续。此时，如果表单的必填项强制验证，用户就无法保存。通过禁用原生验证，我们可以允许用户提交不完整的数据作为草稿，然后在服务器端或通过JavaScript在用户再次编辑时再进行完整性检查。这极大提升了用户体验，毕竟没人喜欢被一个还没填完的表单卡住。
再者，当表单数据通过AJAX提交时，客户端的验证流程通常会由JavaScript在数据发送前完成。在这种情况下，HTML原生的验证机制就没有必要介入了。数据在JavaScript中被收集、处理和验证后，才通过
fetch或
XMLHttpRequest发送出去。此时，
novalidate属性就能避免浏览器在JS处理之前弹出不必要的验证提示，保持流程的顺畅。
还有一些时候，我们可能希望实现渐进增强的策略。即，即使JavaScript被禁用，HTML的原生验证也能提供一个基本的保障。但当JavaScript可用时，我们则提供更高级、更友好的验证体验。在这种设计下，通常会先让HTML原生验证发挥作用，然后用JS代码去“接管”它，或者在JS代码加载完成后，动态地为表单添加
novalidate属性。
总的来说，禁用原生验证不是为了偷懒，而是为了实现更复杂、更符合产品需求的验证逻辑和用户体验。
formnovalidate
与novalidate
属性的区别与选择
理解
formnovalidate和
novalidate之间的差异是关键，它们虽然都用于禁用验证，但作用的范围和场景截然不同。这就像你手上有两把钥匙，一把开整个房间的门，另一把只开房间里某个抽屉的锁，选择哪把取决于你想要控制的粒度。
novalidate属性是加在上的。当它出现时，就意味着整个表单，无论其中有多少个输入字段或多少个提交按钮，其所有的HTML5原生验证功能都会被禁用。这是一种全局性的设置。一旦你把
novalidate加到了
而
formnovalidate属性则加在或标签上。它的作用范围非常精确，只对当前拥有这个属性的提交按钮生效。这意味着同一个表单内可以有多个提交按钮，有些会触发原生验证，有些则不会。
在选择时，我通常会这样考虑：
选择
novalidate
： 当你的表单所有提交路径都不希望被HTML原生验证干扰，或者你已经完全用JavaScript接管了所有的客户端验证逻辑时。这能让你的HTML代码更简洁，因为你不需要在每个提交按钮上重复声明。这对于单用途的表单，或者那些高度定制化、需要统一验证体验的复杂应用来说，非常合适。选择
formnovalidate
： 当你的表单有多种提交行为，其中一些需要原生验证，而另一些不需要时。最典型的例子就是“提交”和“保存草稿”。“提交”操作可能需要所有字段都有效，“保存草稿”则允许部分字段为空。这种场景下，formnovalidate
提供了必要的灵活性，避免了为了一两个特殊按钮而牺牲整个表单的原生验证能力。它允许你混合使用原生验证和自定义逻辑，这在某些混合型项目中会非常方便。
禁用原生验证后，我们该如何确保数据质量和安全？
禁用HTML表单的原生验证，绝不意味着我们可以对数据质量和安全性掉以轻心。恰恰相反，这通常意味着我们将承担起更重的责任，需要通过更强大、更全面的机制来确保数据的有效性和系统的安全。在我看来，这主要体现在两个层面：客户端JavaScript验证和服务器端验证，而且这两者必须协同工作。
首先是客户端JavaScript验证。一旦移除了HTML原生的验证，JavaScript就成为了用户体验层面的第一道防线。它能够提供更丰富、更实时的反馈，例如：
- 复杂规则的实现： 原生HTML验证无法处理“密码和确认密码必须一致”、“至少选择三项兴趣爱好”这类复杂的业务逻辑。JavaScript可以轻松实现这些，甚至可以根据用户的输入动态调整其他字段的验证规则。
- 实时反馈： 当用户在输入时，JavaScript可以即时检查字段内容并显示错误信息，而不需要等到提交时才弹出提示。这种即时反馈极大地提升了用户体验。
- 自定义错误提示： HTML原生的错误提示框样式和位置都比较固定，JavaScript则可以完全控制错误信息的显示方式、位置和样式，使其与网站的整体设计风格保持一致。
- 用户体验优化： 比如，在用户输入邮箱后，可以立即通过AJAX请求检查该邮箱是否已被注册；或者在用户输入身份证号后，自动填充出生日期等。
一个简单的JavaScript验证示例可能长这样：
然而，服务器端验证才是确保数据质量和安全性的终极保障，也是不可或缺的一环。永远不要相信来自客户端的任何数据。用户可以通过各种方式绕过客户端的JavaScript验证（例如，禁用JavaScript，或者直接通过API工具发送伪造请求）。因此，所有提交到服务器的数据，无论客户端是否已经验证过，都必须在服务器端进行严格的重新验证。这包括：
- 数据类型和格式验证： 确保接收到的数据是预期的类型（字符串、数字、日期等）和格式（邮箱、URL、电话号码等）。
- 业务逻辑验证： 检查数据是否符合应用程序的业务规则（例如，用户是否有权限执行此操作，库存是否充足，日期范围是否有效）。
- 安全性验证： 防范常见的网络攻击，如SQL注入、跨站脚本（XSS）、跨站请求伪造（CSRF）等。对所有用户输入进行适当的清理、转义或编码是至关重要的。
- 数据完整性验证： 确保数据在存储到数据库之前满足所有约束（如唯一性、非空性、外键关联）。
我常常强调，客户端验证是为了用户体验，服务器端验证才是为了数据安全和系统稳定。它们是互相补充的，而不是互相替代的。一个健壮的应用，必须同时拥有这两层严谨的验证机制。忽视服务器端验证，无异于将你的数据和系统安全置于巨大的风险之中。
