正如其他人所说，您应该同时做这两项。原因如下：
客户端
您希望首先在客户端上验证输入，因为您可以向 普通用户 提供 更好的反馈
。例如，如果他们输入无效的电子邮件地址并移至下一个字段，则可以立即显示错误消息。这样，用户可以 在 提交表单 之前 更正每个字段。
如果仅在服务器上进行验证，则他们必须提交表单，获取错误消息，然后尝试找出问题所在。
（可以通过让服务器重新呈现表单并填充用户的原始输入来减轻这种痛苦，但是客户端验证仍然更快。）
服务器端
您想在服务器端进行验证，因为您可以 防止恶意用户的攻击 ， 该用户 可以轻松绕过您的Javascript并将危险的输入提交给服务器。
信任您的UI是非常危险的。 他们不仅会滥用您的UI，而且可能根本没有使用您的UI，甚至根本没有使用浏览器
。如果用户手动编辑URL或运行自己的Javascript或使用其他工具调整HTTP请求该怎么办？例如，如果他们
curl从一个脚本或从一个脚本发送自定义HTTP请求怎么办？
（
这不是理论上的；例如，我开发了一个旅行搜索引擎，通过向POST
用户发送请求，就好像用户已经填写了每个公司的搜索表一样，然后将其收集并排序，从而将用户的搜索重新提交给许多合作伙伴航空公司，公交公司等。这些结果从未被执行过，这些公司的JS表单从未执行过，对于我们来说至关重要的是，它们会在返回的HTML中提供错误消息。当然，API会很好，但这就是我们必须要做的。）
从安全的角度来看，不允许这样做不仅是幼稚的，而且是非标准的：应允许客户端以他们希望的任何方式发送HTTP，并且您应该正确响应。这包括验证。
服务器端验证对于 兼容性 也很重要-并非所有用户（即使他们使用的是浏览器）都将启用Javascript。
附录
有些验证 甚至无法在服务器端应用程序代码中正确完成，而在客户端代码中则完全不可能
，因为它们取决于数据库的当前状态。例如，“没有其他人注册过该用户名”，“您正在评论的博客文章仍然存在”，“现有的预订不与您请求的日期重叠”或“您的帐户余额仍然足以支付该笔购买费用”
。” 只有数据库才能可靠地验证依赖于相关数据的数据。
开发人员经常将其搞砸，但是PostgreSQL提供了一些好的解决方案。
