就好比，前端也直接把“可复用的”表单值扔给后端，问就是传了，对象里找找，或者明明需要传很多个业务 id ，这些 id 有关联，就传一个，后端自己查表、调其它服务拿剩下的，还有传个嵌套的数组，后端还得遍历几遍打平拼东西上去等等。数据格式、业务上这种，就看需求开发谁做主了，领导都这么说了，一直这么搞，那肯定有它的理由，虽然现在只是两个字段拼接，但有时候像数组这种数据量大的，特别还是用 react 的话，deep 对比、数据转换，性能会有比较大问题，可能就是不想开这个口子，所以再简单的数据处理也要后端做，前端一般来说数据结构不会经常改的，特别是封装好的业务组件，顶多随着需求加东西。
按理很多数据要前端处理的，但个别前端爱偷懒，只想调接口，不过我也经常帮前端处理一些数据，我觉得不麻烦的就顺手弄了，公司有要求就只能按公司规范做了，如果是那种垃圾公司老油条纯粹想偷懒又掌握不了话语权就只能忍 OR 跑了。另外想起之前有个前同事，一开始不熟，我按业务分接口，他还非要我聚合在一个接口对着页面给他，跟我说这样性能更好，减少网络请求，用户量数据量接口数量都非常小型的项目，还跟我扯这些所谓性能增加我的工作，实际上就是他自己想偷懒 文档都不想看 上班偷偷搞自己的外包项目。
闽公网安备 35020302035485号
1. 用工具直接拉后段文档生成 ts 请求库和类型
2. 直接把设计稿，产品文档，后端技术设计发给 AI
3. 等几分钟，摸鱼一下
然后页面就开发好了。
你刚刚新到一个公司, 还能吵起来, 连试用期都不一定能过, 明天看看气氛不对就跑路吧, 能吵起来估计你也干不长.
如果需要客户端处理，那就要做好不能随时更新内容格式的准备（需要用户更新版本、刷新缓存等，都是不可控的）
你的情况，如果对后端来说加多了工作量，那就以后评估时间就按这种可能有额外工作的来算。