如果您正在进行轻量级验证，最好在客户端上进行。它将节省网络流量，这将帮助您的服务器更好地运行。如果验证很复杂，需要从数据库中提取数据或密码之类的东西，那么最好在可以安全地检查数据的服务器上进行验证。

做服务器端验证而不是客户端验证的好处是客户端验证可以被绕过/操纵:

最终用户可以关闭javascript 数据可以通过一个定制的应用程序直接发送到你的服务器，而这个人甚至不使用你的网站 页面上的Javascript错误(由各种原因引起)可能导致部分(而不是全部)验证运行

简而言之，始终始终验证服务器端，然后将客户端验证视为增强最终用户体验的“额外”。

客户端数据验证对于更好的用户体验很有用:例如，如果用户输入了错误的电子邮件地址，就不应该等到远程服务器处理了他的请求后才知道他输入了错误。

然而，由于攻击者可以绕过客户端验证(甚至可能根本不使用浏览器)，所以服务器端验证是必需的，并且必须是保护后端免受恶意用户攻击的真正大门。

是的，总是可以完全绕过客户端验证。您需要做到这两点:客户端提供更好的用户体验，服务器端确保您得到的输入是实际验证的，而不仅仅是客户端假定的验证。

正如其他人所说，你应该两者兼顾。原因如下:

客户端

您希望首先验证客户端的输入，因为这样可以为普通用户提供更好的反馈。例如，如果他们输入了无效的电子邮件地址并移动到下一个字段，您可以立即显示错误消息。这样用户就可以在提交表单之前纠正每个字段。

如果您只在服务器上进行验证，则他们必须提交表单，获得错误消息，并尝试查找问题。

(这种痛苦可以通过让服务器重新呈现用户原始输入的表单来缓解，但客户端验证仍然更快。)

服务器端

您希望在服务器端进行验证，因为这样可以防止恶意用户，他们可以轻松绕过JavaScript并向服务器提交危险的输入。

相信你的UI是非常危险的。他们不仅会滥用你的UI，还可能根本不使用你的UI，甚至根本不使用浏览器。如果用户手动编辑URL，或者运行他们自己的Javascript，或者使用其他工具调整他们的HTTP请求呢?例如，如果它们从curl或脚本发送自定义HTTP请求呢?

(这不是理论上的;我曾经在一个旅游搜索引擎上工作过，它通过发送POST请求将用户的搜索重新提交给许多合作航空公司、公交公司等，就像用户已经填写了每个公司的搜索表单一样，然后收集和排序所有结果。这些公司的表单JS从未执行过，他们在返回的HTML中提供错误消息对我们来说至关重要。当然，一个API会很好，但这是我们必须做的。)

从安全的角度来看，不允许这样做不仅是幼稚的，而且是不标准的:应该允许客户端以任何他们希望的方式发送HTTP，并且您应该正确地响应。这包括验证。

服务器端验证对于兼容性也很重要——并非所有用户(即使他们使用浏览器)都会启用JavaScript。

附录- 2016年12月

There are some validations that can't even be properly done in server-side application code, and are utterly impossible in client-side code, because they depend on the current state of the database. For example, "nobody else has registered that username", or "the blog post you're commenting on still exists", or "no existing reservation overlaps the dates you requested", or "your account balance still has enough to cover that purchase." Only the database can reliably validate data which depends on related data. Developers regularly screw this up, but PostgreSQL provides some good solutions.

必须始终在服务器上进行验证。

在客户端上进行验证对用户来说也很好，但这是完全不安全的。