现在前端 spa 框架应用如果不做好架构规划，代码审核等约束，是很容易构建出以 mb 为单位的 bundle.js ，再加上很多公司内网的客户端(电脑浏览器)性能并不高，如果再使用 IE 打开，再 ajax 请求上千条数据，是很容易直接卡死的，用户体验非常不好。

以上是我公司内部某个应用整改前的真实情况，这个应用后端开发总是想着只把数据给到前端就行，业务逻辑能让前端做的都让前端做，前端实在做不了的才会放到后端。
整改前，没人觉得几 mb 的 bundle.js 有什么问题，用开发的用的电脑测试没觉得慢，直到有一天领导打开一个页面加载需要 30 多秒，领导强制要求整改。在没有专业前端技术主管的情况下，没有人知道应该怎么改、往哪个方向改，前端代码写得太自由，都揉在一起了，拆分也需要重新梳理需求，整个过程异常痛苦。

相对来说，后端主要是用 Java 开发，强类型保证了代码不能乱写，逻辑至少是可读的，springboot 框架和 mvc 的代码结构深入 curd boy 心，结构清楚逻辑好梳理，光看代码就能看个大概，相比前端一个 ajax 如果不真正执行，返回什么数据我都不太清楚的情况好太多了。

考虑到团队成员的能力差异、异常排查的难度、可能出现的坑的大小、帮别人填坑的难易程度等因素，如果我是项目管理，我也会要求逻辑代码放后端。

对于服务端的开销问题，一般业务逻辑不太容易影响服务器性能，如果真的到了由业务逻辑影响服务器性能的时候，也应该好好审查一下后端代码或者逻辑是不是有问题，一般这种代码或者逻辑放到前端也不一定能顶得住(比如对大量数据做聚合)。