前言

从后端拿到的 list 是散的，需要前端遍历 list 根据 item 的某些属性把同类型的 item 合并到一个 list 中，这样合理吗？我觉得这个不是应该在后端完成的吗？

这种撕扯，让我想起很久之前的一个笑话。我有个朋友之前开发过一款App，其中有一个关于消息发送时间的显示的问题，后端认为给一个时间戳，由前端决定到底怎么显示，你显示年月日时分秒还是年月日时分，又或者是刚刚，那是你的事情。

前端不这么认为

他们觉得这是后端的事情，凭什么要我们写这个逻辑，后来吵了一架，甚至还专门开会去讨论这个问题。无奈前端组有个漂亮的妹子，大家最终还是屈服于团队幸福，后端们强行将这个逻辑冗余到接口中，后来甚至重写了一下json的序列化过程中关于时间类型的逻辑，以减少在所有的接口中去增加这个代码。

东窗事发

直到有一天，用户反馈上来一个问题，那就是他发消息显示的时间不对，明明是早上发的，但是显示是下午。前端组认为我们啥也没改，原样显示的，于是bug交到了后端组，后端的兄弟们查了好久，翻遍了所有的相关代码和数据，最后发现，原来我们这个用户在国外...

后来

后来的故事就更有趣了，前端认为这个逻辑已经这样了，不如在所有的请求的header中增加一个当前的时区字段，后端根据这个字段进行处理，然后后端的老哥们又默默的承受了这一切。并且当时我们有很多接口缓存的逻辑是插入在网关层的，就是缓存的数据已经是格式化之后的json了，这又是一番修改。

你以为这就结束了？

记得最开始说的显示“刚刚”这种文本了吗，用户说我早上发的消息，为什么一直都是显示的刚刚，前端说界面一直没有切换或者退出，数据没有刷新导致的，如果要实时显示需要不停的更新，去调后端的接口。boss终于怒了，毕竟咱们的廉价服务器网络也抗不住这样大量的无意义的请求，前端组这时候也认耸了。

结尾

故事到这里就差不多结束了，所以你认为数据如果只是在显示和组装层面的逻辑需要后端来处理吗？