?前言

從后端拿到的 list 是散的，需要前端遍歷 list 根據 item 的某些屬性把同類型的 item 合并到一個 list 中，這樣合理嗎？我覺得這個不是應該在后端完成的嗎？

這種撕扯，讓我想起很久之前的一個笑話。我有個朋友之前開發過一款App，其中有一個關于消息發送時間的顯示的問題，后端認為給一個時間戳，由前端決定到底怎么顯示，你顯示年月日時分秒還是年月日時分，又或者是剛剛，那是你的事情。

前端不這么認為

他們覺得這是后端的事情，憑什么要我們寫這個邏輯，后來吵了一架，甚至還專門開會去討論這個問題。無奈前端組有個漂亮的妹子，大家最終還是屈服于團隊幸福，后端們強行將這個邏輯冗余到接口中，后來甚至重寫了一下json的序列化過程中關于時間類型的邏輯，以減少在所有的接口中去增加這個代碼。

東窗事發

直到有一天，用戶反饋上來一個問題，那就是他發消息顯示的時間不對，明明是早上發的，但是顯示是下午。前端組認為我們啥也沒改，原樣顯示的，于是bug交到了后端組，后端的兄弟們查了好久，翻遍了所有的相關代碼和數據，最后發現，原來我們這個用戶在國外...

后來

后來的故事就更有趣了，前端認為這個邏輯已經這樣了，不如在所有的請求的header中增加一個當前的時區字段，后端根據這個字段進行處理，然后后端的老哥們又默默的承受了這一切。并且當時我們有很多接口緩存的邏輯是插入在網關層的，就是緩存的數據已經是格式化之后的json了，這又是一番修改。

你以為這就結束了？

記得最開始說的顯示“剛剛”這種文本了嗎，用戶說我早上發的消息，為什么一直都是顯示的剛剛，前端說界面一直沒有切換或者退出，數據沒有刷新導致的，如果要實時顯示需要不停的更新，去調后端的接口。boss終于怒了，畢竟咱們的廉價服務器網絡也抗不住這樣大量的無意義的請求，前端組這時候也認聳了。

結尾

故事到這里就差不多結束了，所以你認為數據如果只是在顯示和組裝層面的邏輯需要后端來處理嗎？