前端开发人员：只负责静态界面、表单校验及相应界面跳转、交互效果的实现
后台开发人员：负责业务逻辑及数据动态内容开发
现测试人员发现：表单提交时，重复点击多次提交按钮，造成数据重复问题。
现在分析：
1 ） 表单提交按钮控制，谁来做？
是前端没有把界面验证做好（例如按钮只能点击一次），还是后台开发没有控制？ 2 ） 什么阶段来验证？
前端开发完成后，没有验证测试通过，还是后台开发人员全部完成后验证？ 后端要验证，防止出错重试或者恶意导致的重复提交，比如二次提交加验证码，比如限制两次提交的时间间隔。
就算前端只能点击一次 api 直接一秒 call >100 次呢
重复表单如果有业务逻辑可以判断重复那后端肯定要加验证
如果没有的话,就是前端的问题啊, 点击提交按钮禁用显示加载动画 等后端处理完 再显示结果+按钮可用就好了.
对于重复提交的问题。
1 、前端点击按钮提交后，loading 改成 true, 按钮改成 loading 状态，此时点击按钮因为判断 loading 为 true 就不执行任何操作了。
2 、后端每个 api 请求可以加个 unique request id，靠这个判断是不是重复请求。
非要甩锅就甩前端，毕竟对后端来说这只能算是流程优化，对前端来说已经算 bug 了(因重复提交导致的数据异常除外)。。。
目前来看，互联网所见的大部分服务都是前端做限制，毕竟前端限制简单粗暴快，只要前端做好后端基本不会受到重复数据了，只有 hacker 会破解前端来重复提交，不过对 hacker 来说做这种简单后端限制意义也不大
有些框架倒是自带了后端验证，但是个人不是很喜欢
– 比如通过按钮失效来告诉用户点击成功了（不然用户会烦躁 “究竟点到了没”）
– 比如通过进度条（或转圈圈）来告诉用户正在处理中。
后端的主要负责对象是公司（公司数据的安全、服务器的稳定），最主要的责任是假设每一个请求都有可能是攻击。
另外，用户点击按钮的 “使用体验”（能感觉到点击生效吗、能感觉到正在处理吗）则是前端的责任。
如果用户体验不好，烦躁地多次连击按钮，这个烦躁应该由前端负责解决，但后台数据是否重复这个前端是解决不了的（因为还有攻击者不走正常前端页面）。
前端控制点击状态是为了避免双击或者网络不佳时有人多次点击。另外，每次进入这个页面的时候，前端最好生成一个 key，表单提交的时候带上 key，用于后端判断是否多次点击。（当前端判断请求失败 /允许再次请求的时候，前端才会刷新这个 key ）
同样的，对于响应速度一般的接口（尤其是插入，容易造成业务数据重复）后端要采用 用户-key-接口 为单元的锁。
前端是交互问题, 比如 disable 什么的
哪怕前端不做, 后端也应该返回错误提示
你的 80%是怎么算的？
前端做是考虑用户体验，后端做是考虑数据安全。前后端各自基于不同的角度去考量，还能分出个后端 80%，前端 20%的占比来？
笑话！
前端再次被害，果然后端的眼里前端就不是开发，还好我正在转后端 ing
1.假如是今日签到的按钮，后端肯定要做禁止重复签到的检验。
2.假如是后台发文章的接口，如果后端有标题不能重复的判断，自然也就没法重复提交。
3.假如还是发文章或者评论，并没有什么业务上的字段非重复要求，后端就没必要特殊处理，就算处理也是防止灌水处理吧。
以上所有场景前端肯定应该做按钮 disable 处理的，前两个场景是正常的错误提示，最后一个场景是防止非预期的“灌水”。