问老开发一个前后端矛盾的问题

前后端矛盾

数据处理

组件复用

195 条回复 • 2025-07-31 17:44:11 +08:00

1 2

❮

❯

101

Lexin914

2 天前

谁做都行，谁空谁写，我们公司基本都商量着来

102

yishidixia

2 天前

controller 层不做这个，那直接把账号密码给前端，让前端自己连数据库取数吧哈哈哈哈

103

test00001

2 天前

@lthon 没错，就比如我们总监是前端，后端苦不堪言

104

ceilingyear

2 天前

我是前端，感觉不大合理，后端数据结构需要考虑复用性不一定和前端能一一对应，前端需要做必要的数据处理；只要后端返回的数据格式不是太屎，前端都该自己做处理；

105

abolast

2 天前

@CodersZzz 我没说清楚，我是运维，所以我能看到所有代码，目前是有代码权限人管理的，不过后期我想对所有开发都开放权限，反正提交是有记录的，全部开发都能看别人的屎山代码可能是有利于代码质量，运维开仓库也简单不需要考虑权限人直接添加一个仓库么字段执行就行了。

106

fruitmonster

2 天前

如果能减少数据包体积，能复用则应该复用，如果复用增加工作量，或者响应时间，那再给一个也无妨，反正前提就是省！省请求、省体积、省事！

107

worldhandsomeboy

2 天前

1 、前端所有接口都希望后端返回的数据能直接使用，不进行任何数据处理，这个合理；
2 、状态返回 01 他们要 truefalse ，看情况；
3 、两个需要拼接的字段都返回了，还要增加一个汇总字段，这个不合理；
4 、甚至前端渲染图表，list 数据已经返回了，他们要我转换成图表需要的多维数组，这个看扯皮。

108

irisdev

2 天前

01 和 truefalse 对前端有区别吗

109

laminux29

2 天前

如果说前端说的有理，那么原因就是前端兼容性差、运行效率低，数据的确适合后端全部做好后，前端直接从后端拿，前端不建议再去对数据做处理。

但如果说前端说的没理，那就是考虑到工作量与工作公平性的问题了。这需要公司内部进行讨论协商。

110

duanxianze

2 天前

小程序开发，后端能做的，一律后端做，前端发版麻烦死了，其他的，就看谁的话语权大了，各有优劣

111

duanxianze

2 天前

@irisdev 有 Boolean("0") == true

112

yxzblue

2 天前

数据结构都是后端处理
只返回前端必要的字段，拿来就能用的

113

chill777

2 天前

不如把数据库整个给前端，让他自己查去

114

h1298841903

2 天前

1

按理来说，应该按照前端的要求提供数据。比如：01 ，前端根本不关心后端内部怎么存储的，前端只需要 true/false ，这样文档上也清楚。汇总字段也是比较常见的，前端只关心有这个字段，不关心这个字段是怎么来的。

115

irisdev

2 天前

@duanxianze 后端肯定返回 int 0 吧

116

Richared

2 天前

前端要啥给啥这没问题，数据格式转换这个肯定前端做呗。这一般都是图表类的，前端都有组件的。

117

erwin985211

2 天前

现在处理数据，直接让 ai 写函数不就行了。以后我可能会让后端处理一些很复杂的逻辑，现在随便返回，只要有我想要的数据就行了。直接问上级什么处理，让你处理你加工期就行了。

118

Richared

2 天前

顺便说一下，怀念当时写 jsp 的时候。

119

drydiy

2 天前 via iPhone

我是前端。你描述的问题，都是前端应该解决的，我带团队都是要求后端大多数情况只返回数据，页面怎么展示让前端处理。少数情况前端不好处理或者影响性能就让后端帮忙处理。

120

xiaofeixiang

2 天前

会提前协商给什么格式的，后端不好处理就前端写代码切换格式，前端还更好处理容错

121

leoQaQ

2 天前

作为前端，我一般是能自己处理就自己处理。后端给的数据结构实在是太奇葩的情况下才让后端处理。PS: 没有说后端不好的意思，只是有时候后端不了解前端需要什么格式。

122

MHPSY

2 天前

前端处理不会很麻烦，按理说是应该前端处理

123

hqmJoker

2 天前

@esee 啊？我也是有时候前后端都写，如果没有规范要求，且涉及比较复杂的转换时，我会倾向于使用自己熟练的技术栈写（也就是前端写），因为使用不熟练的技术栈写，会增加我的开发时间，而且有时候我也会漏掉一些东西，使用熟悉的话基本一遍就过了，调试修复测试流程也比较通畅

124

kkwa56188

2 天前

看到这里，前端内部意见已经都不统一了，
所以这个事情更准确的描述是 “部分前端人员要求后端给的数据直接能用”

125

blessyou

2 天前

这么洁癖，你加一个数据转业务层。

126

hellomimi

2 天前

如果没有规范明确哪一边做数据处理，
那么可以尝试或者回想一下自己写过的个人项目，前后端都自己来写，看看处理数据是哪边来处理的就知道了。
己所不欲，勿施于人。

127

pointerman

2 天前

虽然但是，前端要啥，你就给啥

128

MRG0

2 天前

最好就是按照以前的写法来

129

duanxianze

2 天前

@irisdev #115 就是因为 js 里面 int 0 很容易被转换成 string,比如路由参数，比如 cookie ，比如 cookie,之前有些厂为了避免这种情况 js 判断甚至用的 string "true" "false" 我都服了

130

dabennn

2 天前

作为一个老前端，只能说我不在乎数据是不是要拼接或者转换，我只在乎我要用到的数据怎么组出来后端得明确的告诉我，包括多分支的情况用什么字段去判断。还有就是只能接受在一个接口的数据做转化，要是要我用两三个接口的数据去组一份数据出来，我会骂人

131

hellomimi

2 天前

忍不住再回复一下，哈哈哈🤣，逐条分析：
1 、01-truefalse ，前提需要知道 01 的类型，
如果是数字类型，那么对于前端来说这和 truefalse 没区别（除非前端特别菜）。
如果是字符串类型那么对于前端就很比较操蛋了（虽然常规 99.99%是 int ，但我见过给返回字符串的）。
2 、拼接的字段，前提也需要知道类型，
如果是字符串那么当然前端拼接一下很方便。
如果是数字类型，比如两个字段拼接计算总价，js 处理可能会出现精度丢失的问题，还需要额外引入一些第三方库来解决精度丢失问题；
3 、渲染图表，这个情况基本都由前端处理数据格式，前提需要后端给到的数据完整。
比如给 list ，前端需要自己转成树结构数据，那么 list 里的 parentId 、childId 肯定是必要的，如果没有这些必要字段，前端肯定会和你来扯皮。

132

crocoBaby

2 天前

大佬怎么说就怎么做,前后端吵没意义

133

pagxir

2 天前 via Android

前端是啥，前端是干展现的活，怎么可能要求跟后端一一对应呢。

134

Yjhenan

2 天前

@irisdev #115 有些返回的就是字符串数字，甚至还有字符串 null ，后端老大都看不下去了

135

ainyyy

OP

2 天前 via Android

@kakki 哦，我们的二维码就是，一个客户扫码跳转的连接。返回地址不行，要后端转正二维码保存，在给他们反二维码图片地址。我看到前人数据库存个这玩意还不理解，直到和前端吵了一架

136

cein

2 天前

上家公司前端，让我列表把序号返回给他，说没序号不好显示，就该后端返回, 我？？？

137

dcsuibian

2 天前

我是全栈
1 、数据转换是程序员的基本能力，跟前后端无关
2 、如果代表是否的话，true/false 确实比 0/1 更合适，从语义上更合适，而且类型更正确
3 、我觉得你后端就不应该太管表示层的东西，只要确保前端有能力拿到就行

全栈就不太存在这个问题。前端做还是后端做完全看我觉得哪边方便、哪边通用性强，组里谁要感觉不行就甩手给他写一段前端代码或者后端代码

138

casphere

2 天前

我是前端都是我在搞不费事吧

139

buffzty

2 天前

方法 1: 你让他写数据格式设计 api 然后你按照这个做就行.他既然想偷懒你就把最累的工作给他.他如果不设计你就说你怎么知道它要什么数据.
方法 2: 一步到位跟他要前端设计图直接给他返回 html,这下他什么都不需要做了

140

bzw875

2 天前

我是前端，除了计算金额的，和无法计算的。通通前端自己转码。不会就开除
然后招聘前端面试题要求 5 道题 leetcode 选 3 道题算法题做不出来没有二面

141

fengyenobug

2 天前

看情况，凡事都有个度。
1. 比如 true false 后端给 01 的，如果只是一个简单的结构，前端处理，如果你这个 01 在很深的一个 json 里面，而前端又要直接用 true false ，他就需要先 map 整个庞大的 json 数据，前端肯定觉得不合适，让后端处理。
2. 我看评论区很多全栈说，这是前端偷懒，后端写一个接口不用动，前端页面改了还是可以重新处理再复用这个接口，但是实际业务极少这样，或者就是新老版本同时存在，一般使用不同的接口。
3. 还有的后端，前端渲染列表每行数据只需要三五个字段，结果一个对象返回二三十个字段让我在里面找，不说别的，20kb 能传输完的数据，有必要传输 200k 吗，用户量大的时候服务器为什么要多这么多无用的流量，查个库查个表就直接扔给前端了，数据都不怎么处理的那肯定不行，如果前端再需要处理一下，就要遍历你这个庞大的数据。
4. 还有一些是给的数据前端确实不好用，不是说组件的问题，而是前端需要处理好几遍接口返回的数据，最后这段代码就成了只有自己看得懂的，而实际上他就是个普通的数据处理，但是如果有改动需求，就需要再次理解这些代码，如果换个人改那就更影响效率，这是亲身体验。如果前端处理少一些逻辑就会清晰很多，有改动的话也好改，如果真的需要后端改接口的地步那就是业务逻辑大改了，还想复用接口那肯定是后端偷懒，实际上业务稳定的话很少改，除非升级版本（升级版本刚开始也是新旧并存的，老的也要继续，新的接口还是得写，我们公司的逻辑是接口一旦上生产，只会新增不能修改，因为你不知道哪里在调，有的客户有可能还在用之前的老旧版本，已经上线的接口是不能动的，只能新加一个）
5. 当然了，如果前端只等着饭喂到嘴里那肯定是不可能的，简单的数据确实需要前端处理，但后端本职工作就是为了处理数据的，前端更注重与页面逻辑和用户交互，必须要有明确的界限，如果很多复杂数据的处理都让前端做了，那后端的意义在哪呢，回到题主的问题那就是要有个度，没有具体情况不做具体评判
6. 纯渲染的前端处理数据没什么，但有些业务，前端也需要根据不同的状态做很复杂的判断来渲染页面，这个时候数据结构肯定复杂一些，再让前端处理数据那就说不过去了
7. 说说我自己遇到的，一年级到六年级，每个年级有几个班，
一般是 data = [
{
grade: '一年级'，
class: [{classNum:'01',....},{classNum: '02',....}]
}
{
}
]

142

chendadaover

2 天前

根据我的经验, 纯粹就是前端觉得增加了工作量, 这个时候就看谁更有话语权了

143

fengyenobug

2 天前

@fengyenobug 但有同事给我的接口千奇百怪，年级名当 key ，内容当 value ，写了三年前端只有这个后端给的列表接口是这样的，前端能处理，但每次都得处理而且麻烦。
现在我小组的这个后端，写接口之前会先来问我需要什么样的数据结构，最幸福的一次。

144

gorvey

2 天前

我只看接口文档写的详不详细，后端给什么样的格式/需要什么格式都行。只要不太离谱的都无所谓

前端的业务除非是那种特别简单的 crud ，不然都要格式化的，数据格式的转换也是顺手而已

145

zhuweideng

2 天前

直接后端，前端一起写，让前端同事失业！

146

NessajCN

2 天前

这传什么字段是你们前后端自己定的啊？你们没技术总负责人的吗？项目经理呢？

147

zagfai

2 天前

谁写的文档谁决定

148

linshuizhaoying

2 天前

有了 ai 这种问题都不算问题。你可以按自己想法写完结构。让 ai 自己处理成前端要的返回加个函数而已。

149

dongdong12345

2 天前

有的接口可以，有的接口不行。

150

leelotov2er

2 天前

@visper all in graphql 算了

151

GothamClown

2 天前

你们有多个不同的前端(Android/iOS/Html) 的时候，后台处理业务会比较好。如果是只有一个，那谁声音大就听谁的

152

Sfilata

2 天前

我也做全栈，我倾向前端加一层转换层，定好原始数据结构和视图数据结构，然后可以用 AI 写一下转换逻辑就可以了。这个都不用动脑子。但如果后端的数据东一榔头西一棒槌我肯定不会同意的，你好歹原始数据要完整可用，一堆 null 或者要查好几个接口肯定不行。

153

vaporSpace

2 天前

就你提到的内容，一般应该是前端做。但老听到后端说: “前端有啥业务逻辑，不就是拼一下组件吗”，那还是后端做吧，能者多劳

154

cnhongwei

2 天前

这个没有标准啊。我是前后端都做，但我的前端使用的是 react 和 react native ，业务复杂的时候，在前端做判断很麻烦，前端做了几个可能性判断，隔几天可能又要加一个，用户的 app 可能更新，也可能没有更新，后端做兼容也很麻烦，所以经常就是后端把所有的逻辑都处理完了，把前端要弹窗的内容都输出后，前端点按钮调用，把返回结果做弹窗就完了。另外，前端处理数字运算比较麻烦，所以前端一般也不做计算，当然数据转换一下还是可以做的。对于公司来说，统一的处理方式比较重要，不要一会儿这样，一会儿那样，所以按惯例来处理最好。

155

mameng

2 天前

我一个前端当年直接拉数据库比较原始数据做边缘计算，因为后端处理压力大。

156

nekoneko

2 天前

你跟领导说把前端开了, 你前后端一起做.

157

thevita

2 天前

抛开团队现状等情况不考虑的话，我一般遵循 "领域知识最小跨越边界" 原则，即某个知识、约束、规范来自某个人、模块、团队，那就尽可能让这部分约束限制在这个人、模块、团队内，完全把这种责任丢给某一方长此以往都会导致协作成本不断上升

具体到这个问题，图表的多维数据应该由前端来处理，后端也要建立相对标准、稳定的模型（具体做法可以参考前端的模型），不然前端换一个图表是不是还得改后端接口

158

laifu123

2 天前

看到贴里一些后端还挺傲慢的，对前端来说返回的数据能用字段全就行，处理数据谁都能做，没规范就看谁的声音大了，0/1 转 true/false ，语义化上来说更清晰，不转也无所叼谓对前端来说就一个判断，如果前端一个组件已经复用了多个业务了，新接口返回又是奇葩数据，那前端确实会和你扯皮下

159

THESDZ

2 天前

本质上是因为，前后端对于业务模型没对齐，前后端应该对齐业务模型。
说白了，产品梳理需求后定义功能，根据功能前后端定义最佳实践中的接口文档，然后就是对照文档。

160

wx497657341

2 天前

直接把前端的活儿抢过来，整天假忙，让他们回家睡觉去

161

visper

2 天前

@leelotov2er 可能这就是 graphql 的初衷吧。也许 facebook 那些后端也觉得前端查询数据格式变化太多了。所以烦了搞了个这东西出来。

162

cdj123

2 天前

这种情况太正常了，有很多前端缺乏基本的数据结构知识，稍微复杂一点的处理他们就跟脑子转不动了一样。我前端也做过一段时间，我自己的理解前后端的职责就应该像做菜一样，后端负责提供稳定的食材，具体怎么切割、拼盘应该由前端处理，很多时候明明一个循环就能解决的问题，非要搞到后端做。这种情况一般你向上反应也没用，本来就是没有标准的事情，怎么做全看领导心情和前后端话语权

163

poorcai

2 天前

就是你以前遇到的前端人太好了啊。这让我想起来我在前司和一位妹子前端打配合，讨论需求时都是轻言轻语、不急不躁的，她不好处理的我就接过来，我不好弄的就让她处理，没有发生过任何矛盾，真的怀念。

164

anghunk

2 天前

按道理来说，你举得几个例子都应该由前端来做，比如图表，后端返回一串 data 就够了，具体怎么渲染，产品肯定还得改，但是改动的部分基本不会涉及数据，所以前端处理比较合适，一些简单的计算，0 1 这种就不说了，肯定是你们前端偷懒

165

importmeta

2 天前

@shawnsh 呵呵, 戳到你那里痛处了? 你被这样开除过? 我爱说什么就说什么, 你算老几?

166

WithoutSugarMiao

2 天前

工作七年，两年全栈，五年后端。我和评论区意见可能不太一样。这并不是什么扯皮的问题，也不是规范不规范的问题（当然领导要求另当别论），而是前后端职责分配的问题。前后端分离最主要的目标，不就是能让前端专注于页面交互，而后端进行数据处理吗？你又让他自己去做转换数据，那不是又把前后端分离的界限模糊了吗？

都工作八年了，我觉得不太应该问出来这种问题。虽然我自己工作的时候，也遇到过高手前端，让我直接给数据就行，他来处理格式什么的。但是这不代表这是前端的主要职责，前端帮你做的是人家做的好，而不是人家应该做的。

167

importmeta

2 天前

@shawnsh 吵架本身就是大忌, 还是试用期, 怎么就是阴阳怪气的给人家泼冷水了? 你一个新人进去就吵架, 还指望在那干? 另外怎么国企项目就一坨屎了?

168

QlanQ

2 天前

@WithoutSugarMiao 你这才是模糊了吧，让后端按照前端组件需要的数据格式返回，这不就是把前后端又耦合在一起了吗？
分离的意思就是，你玩你的，我玩我的
你给原始数据，我想怎么玩就怎么玩
而不是前端组件定义好数据格式，你后端必须按照前端的格式来，如果格式不正确，前端页面就崩了。

假如一个列表的页面，后端返回一个列表的数组，

但是现在前端页面有两种展示方式
两种方式使用的是两个组件，两个组件的格式不一样，例如一个是一维数组一个是二维数组
难道同样的数据，后端要分两个接口对应两个组件吗？

169

seth19960929

2 天前

后端负责业务逻辑层：返回 “领域模型的原始数据”
前端负责展示层处理：把后端的原始数据转换成 “UI 需要的格式”

楼上是不是歪了, 前后端分离本质不就是把后端拆分出来吗?以前后端自己转换数据渲染到页面上
反驳楼上几个点

1. 后端转了, ios, android, h5 可以直接用
> 错, 那只是为了偷懒而找借口, 后端应该专注于业务编程, 而非页面编程

2. 状态 0, 1 和 true / false
> 取决于业务, 是否只有禁用或者启用, 比如, 用户 true 可以正常使用, false 不能使用, OK, 但是如果有需求 0 正常使用, 1 不能使用, 2 注销中可以使用基本功能类似这样

3. 图表数据格式问题
> 如果前端用 echart 就转成 echart 格式, 用 dchart 就转成 dchart 格式, 岂不是问题很大, 或者安卓和 ios, h5 用不同的图表组件, 那怎么适配? 所以只返回 “领域模型的原始数据”

170

yeka

2 天前

前端做数据处理的话，一有需求修改，改前端代码，重新构建部署。后端的话就不用了。当然，也不是说都要后端处理，视情况而定了。你能理解前端就改个字符然后需要打包部署一套下来要不少时间。而这些字或字符明明也是可以做成接口传给我的。但某些后端就是不情愿你有什么办法呢

171

BenHunDun

2 天前

@yeka 后端也要看什么语言吧. 有些也是走构建部署的方式.
我认为其实还是要根据接口含义, 业务去做这些.

像后端肯定要考虑接口语义, 数据是否有过多暴露(是否接口粒度过粗). 然后包括接口业务上的事务性.
也要考虑到前端处理某些特大数据情况下的用户端机器性能的问题.

状态 0, 1 和 true / false > 像这种数据我感觉不是深度嵌套的情况下, 其实感觉还好.

数据处理, 大部分情况下前端, 后端都是能够做. 总有一个人要做.

172

seth19960929

2 天前

@yeka 后端的也需要打包部署一套, 时间更不少, 你看看服务端构建镜像, 部署整套服务, 快的话几分钟, 慢的话小时级别.

所以本质还是看像不像偷懒了

173

uselesswater

2 天前 via Android

1

前端不处理，我以后就只能叫他切图仔了。

174

kamal

1 天前

改，也是要花时间的。
上班的时间，做什么事不是做？

175

z1829909

1 天前

@viweei
给前端能有多少数据, 除去一些特殊场景, 普通的 API 给个几百条数据, 你就算把他遍历一百遍, 相比较网络等待时间和渲染消耗的资源, 都可以忽略.
缓存方面后端有自己的缓存策略, API 本身获取的就是经常变动的数据, 如果在 API 维度做缓存利用率很低, 所以会在更底层的数据, 不经常变动的部分做缓存.
另外假设后端满足前端了, 给的数据结构就是和页面结构相似的, 那前端就不考虑复用了吗, 意思是一个新功能开一套 API, 功能如果变动, 还要后端去改代码, 前后端分离的意义是啥呢.

这个我的经验是, 能力越强的前端, 他越是想后端提供基础通用 API, 因为这样他发挥的空间才大, 可以用基础食材组装出自己想要的东西, 所以前端才折腾出 bff, graphql 这些, 本质上就是前端不想要搞点什么都要找后端配合, 想要更高的自由度.

176

belowfrog

1 天前

必然是前端干啊，后端接口应该是多个前端的最大公约数，比如有 app/网页/小程序这些，难道每个前端都要适配一个？而且前端逻辑改了，还要后端去改接口返回？？

177

cloudzhou

1 天前

这个取决于大前端还是小前端
严格的前后端分离，应该后端数据为主，前端做展示逻辑
但是前端人数很少的话，后端也顺手 view 层把数据做掉了

178

royzxq

1 天前

放在以前应该会有人来推销 apijson ,但这哥已经很久不出现了

179

realpg

PRO

1 天前

前端的毛病
大型系统都是在前端消耗用户计算力来做这些事儿甚至那些 join 操作都是两组数据给到前端循环交叉

180

areless

1 天前

就拿 mvc 架构来讲。现在的前端能写 v 也能写 c ，用上 GraphQL （或 apijson 哥）之类的也能写 m 。但是你的产品想要靠谱，安全方面不是玩具级别的，最好研究一下互联网那些应用为什么分前后端吧。就拿 05 年到 08 年的东西来说，前端那时候就 v 层写 css 的，js 大部分会引起浏览器告警的功能全部不能写。百度那张用 css 及安全 js 适配 ie4.0 的 logo 也才是近几年才撤下的，别太奔放了后端 CURD 仔，统计你不会没用时序数据库吧？模糊查询用 like ？什么？还在用欧式距离？矢量余弦都不会？你看阿里前端仔都用上 midwayjs.org 全栈了，你不会还在 curd 吧？一年经验用八年？

181

areless

1 天前

@belowfrog 你是做了多健壮的接口？挂个链接试试

182

Hieast

1 天前

大公司和小公司不可一概而论。小公司别说后端拼页面元素了，前后端是一个人不分离的都有。大公司 to C 的接口管理比较复杂，要区分版本，尽量要向前向后兼容，要支持三端，要同领域业务内聚，那题主描述的内容就不适合放底层接口了。事实上放前端也有问题，有的数据前端处理确实困难、或者需要编排多个底层接口，确实需要一层来编排接口处理数据提升性能，所以大公司招的全栈工程师会用 Node 写 BFF 层。

其实只要大家工作量差不多心里能平衡，怎么分工都行。但是能讲清楚为什么怎么分工最适合当前的业务，新招几个人怎么安排，碰到机会了才有可能抓住。

183

areless

1 天前

大前端，用 nextjs 这类的框架，都自带调用 sql curd 时序向量数据库等功能了。而且 nextjs 是跑在后端服务器的，安全性也不差。这种前端连理都懒得理你，怕你黏上要给他写后端。大前端全干，假设一个月能做完全干的项目。但是这个人突然想不开拉了一伙 java 仔来 curd ，这个项目工期起码就得三个月以上了。记住历史，java 之都在一直都不是杭州，是印度。