看到大家吊打后端，我來歪個(gè)樓。

首先，對(duì)于題主描述的 PHPer 吊打無疑，但并不是所有接口都可以隨心所欲按照前端的要求來做，目前主要遇到幾類接口：

1. 代理其他系統(tǒng)接口過來的(沒法改底層，要轉(zhuǎn)換需要自己轉(zhuǎn))。

2. 帶有歷史負(fù)債并且比較底層各個(gè)業(yè)務(wù)方都有依賴的接口(沒法改源頭，只能新開接口)。

面對(duì)以上兩類接口，前端轉(zhuǎn)還是后端轉(zhuǎn)就需要整體考慮下：

1. 開發(fā)成本。前端 JS 對(duì)于數(shù)據(jù)轉(zhuǎn)換有一些天然優(yōu)勢(shì)，特別是對(duì) JSON 的處理，成本小。后端 Java 等很明顯成本要高的多。如果時(shí)間緊急，還是要前端填坑。

2. 穩(wěn)定性和可維護(hù)性。對(duì)底層業(yè)務(wù)代碼的修改，代碼爛的話，可能會(huì)對(duì)穩(wěn)定性產(chǎn)生影響。可維護(hù)性一般是比較容易扯皮的地方，按照前端要求輸出，后端可能要多做一些事情，按照后端輸出前端就要多做一些事情。因?yàn)殚_發(fā)的思路和習(xí)慣真的有差異(前端：我不管業(yè)務(wù)邏輯，數(shù)組給我循環(huán)、循環(huán)、循環(huán)。后端：我不管你怎么用，直接把數(shù)據(jù)庫原始模型存進(jìn)去的數(shù)據(jù)給你撈出來不就好了。)這也是為什么好的架構(gòu)師是前后端都會(huì)的原因，只有前后端都開發(fā)過比較熟悉，才能結(jié)合兩個(gè)領(lǐng)域的開發(fā)習(xí)慣和思路，設(shè)計(jì)出開發(fā)效率更高的系統(tǒng)架構(gòu)(按照數(shù)組存儲(chǔ)，模型、數(shù)據(jù)貼合 UI 但保留業(yè)務(wù)擴(kuò)展性)。

===

對(duì)于樓主這個(gè)問題，我一般都是提前溝通下，后端新做接口的話，我提前出一套結(jié)構(gòu)和約定，后端用老接口，我會(huì)讓他先拉一份 Mock 數(shù)據(jù)看一下，然后進(jìn)行一些調(diào)整，沒問題了發(fā)郵件出來。到了后期聯(lián)調(diào)的時(shí)候，如果是后端結(jié)構(gòu)不符合字段、結(jié)構(gòu)等要求，除非是底層硬傷實(shí)在無能為力之外，不管修改他成本大小(雖然我只是改個(gè)名字)一律按照最初約定的郵件來改。

總結(jié)

以上是生活随笔為你收集整理的后端传前端中文显示都是问好_前后端分离，后台返回的数据前端没法写，怎么办？...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。