(Proudly powered by QKQ)
最近有个项目，其采用了前后端分离策略，架构师提出：仅在前端作验证，后端不作验证，认为传入的数据是已经在前端经过了充分验证了的。提出这个的原因是该系统为内部系统，仅有内部人员使用，如果出现有人绕过前端，直接访问后端的情况，可以做事后处理和追溯。
那么，针对普通的项目，应当如何处理前端验证和后端验证呢？
Q: 这里的验证的场景是什么？
A: 比如说，用户注册。用户需要填写一个表单，输入诸如用户名、密码、邮箱、公司等信息，点击提交，完成注册。
其中，这个表单需要验证，可能的验证规则有：
- 用户名不能有特殊字符，如%￥#@&
- 邮箱必须符合正确的邮箱格式，如koly@123.com
- 用户名不能重复
- 密码必须包含数字、小写字母、大写字母、特殊字符，且长度不能少于8位
Q: 前端验证和后端验证都是必须的吗？
A: 从必要的角度来说，前端可以不做验证，但是后端的验证是必须做的。
为什么呢？
前端不做验证，但是在表单提交的时候，后端验证的结果会返回前端，前端需要解析结果，显示对应的内容。对于验证不通过的情况，需要展示相应的不通过的原因。
后端验证一定要有，是因为后端才是接收数据，并对数据进行操作和存储的。只要保证了接收到的数据有足够的验证，就能保证最终存储的数据是满足了业务验证条件的，不是“脏数据”。
如果仅有前端验证，没有后端验证。在前后端分离的情况下，用户可以绕过前端，直接访问后端接口。那么前端验证也就失效了。也就等于没有对数据的业务验证了。
同时，如果仅有前端验证，部分验证功能不好满足。比如判断数据库是否存在相同的用户名，此时需要查询数据库才能判断。如果前端不同后端交互，那么是不清楚用户名是否重复的。
K: 后端有，前端可无
Q: 前端验证和后端验证都是对同一个数据的验证，有什么区别？
A: 二者的目的不同：
- 前端验证是为了提供更好的用户体验；
- 后端验证是为了保证数据满足业务条件(business invariants)；
有了不同的目的，我们在设计前端验证的时候，其出发点是更好的用户体验，即更好地引导客户舒适地完成表单的正确填写。比如针对密码设置，使用提示信息分行列出密码的规则，当密码输入完毕之后，实时检验验证规则是否满足，对于满足的规则，展示为绿色，并在规则前打勾，不满足的规则展示为灰色，并在规则前打叉。
K: 前端体验，后端保证
Q: 为什么一般都是前端验证和后端验证同时存在？
A: 综合上述两个问题的答案：
- 后端验证必须存在
- 前端是为了更好的用户体验
所以，追求用户体验的情况下，二者都是需要的。
Q: 后端验证就是数据库限制么？
A: 不是。数据库限制仅是数据上的一些约束，比如一个表里面的varchar长度最大为40。
除了数据库限制之外，还有业务限制。比如这个varchar的具体内容应该满足什么样的格式。以上述的注册表单为例，可能使用varchar(256)作为存储邮件，但是数据库并不会验证其值为正确的邮箱格式。
K: 业务限制，数据限制(constraints)
参考资料：
[1] https://stackoverflow.com/questions/17039934/is-it-practical-to-have-back-end-database-side-validation-for-everything
[2] https://stackoverflow.com/questions/162159/javascript-client-side-vs-server-side-validation
[3] https://www.quora.com/Should-I-do-input-validation-on-the-front-end-or-back-end
