前后端矛盾，大家都怎样处理的？

数据的格式：graphql
数据格式验证：前后端都要做
防重和并发问题：都要做

看你们团队谁强势一点咯

1. 看谁拳头大
2 ，3：后端必须要做，前端最好可以做

1.后端
2.都校验
3.都要做

第一点，有 BFF ，前端做，没有 BFF ，后端聚合
后两点，前后端都要做

很多边界问题 没有唯一的准则。大多根据
1. 谁受益谁来做
2. 两边都能做的情况下，衡量 ROI ，很多情况下需要有话语权的人判断和拍板
3. 如果你水平足够，代入到领导的视角，如果你是领导，你会让谁来做？此时你会脱离自身利益，看问题看得清楚些

回到你的具体问题
1. 数据结构：前后端应当维护一个资源结构并达成共识。后端返回共识的结构即可。后面 UI 有变动导致的 数据渲染（表示）层变动，前端来处理就好。即，不考虑 UI 具体结构，只从资源关系上定义好数据结构。

2. 用户输入验证：
- 前端：应当最大限度把不合法的请求拦截掉，避免对服务端发出无用请求，从用户体验来看，也会更好。但一些重逻辑的判断，可以透传给后端判断，避免前后端不好维护这类重逻辑。
- 后端：必须要判断。永远不要相信用户的输入时第一原则。微服务中的内部服务间的“前后端” 则看具体设计和取舍了

3. 并发和防刷
- 前端：要做。考虑的是用户体验 和 后端压力的缓冲。
- 后端：看具体需求决定，有些无关痛痒的需求就没必要加锁了，前端做了就行。涉及金钱或者会影响需求的正常实现的，那就必须要做了，否则就是 bug 了。

关于 BFF (前端来做的话)...
看到过一段描述: "矛盾一直会存在, 只是 BFF 把这一层矛盾由 '敌我矛盾' 转变成为了'人民内部矛盾'
XD

1. 后端转成树结构（利用递归或者 ORM 框架，一般是后者）
2. 前后端都需要做，比如对于电话和邮箱验证，前端可以不请求接口就完成，而且可以做用户操作，比如让输入框抖一抖，使用同一套正则比较好
3. 前后端都需要做，前端按钮防重其实也属于产品设计范围内

不分离的时候都是一个人做的

后端做，前端选择性优化

1. 我希望是后端做, 不做也没法, 丢递归里处理下
2. 前端后端都要做, 正则匹配下非空和格式, 等到提交再报错体验不是很好
3. 不太明白指什么, 不知道是不是防抖的那套, 反正我是 loading, 遮罩层, 防抖都看情况上

2,3 前后都做，前端做是为了用户体验、后端做是为了安全

上面的回复说 2 ，3 前后端都做，楼主不要有后端可做可不做的错觉，不管前端做不做，后端一定要做的。你有用 postman 调过后端接口吗？ postman 会帮你校验参数吗

1. 前端
2. 前端 + 后端
3. 前端

@foam 如果说对于 2 ，3 问题后端就是不做，怎样处理这个问题呢？或者说有一方就是偷懒，不做。抛开从技术处理的角度来说，怎样避免这样的问题发生？前后端的工作职责应该怎样划分？团队的管理应该怎样处理这样的问题？

数据校验后端不做是挺严重的安全问题啊，这个技术老大能允许？如果真允许那就不用管，反正前端一般也要做校验，真出了事也赖不到你头上，然后找机会换个公司吧。

我觉得拦截验证，叫不准会不会变的规则，前端做轻拦截就行，比如手机号多少位之类的，因为号段会不断变化

针对于 iOS Android 这种客户端

@lindenYou
在技术设计评审环节需要有人把关，如果后端没有人懂这个或者后端 leader 也不想管，要么他换人，要么你跑路。