前后端接口联调时候后端应该处理数据之后再给前端吗

比如标签状态，后端定义 0/1/2/3/4 这种，前端在标签这里是直接显示比较好，还是前端拿到原始数字去查字典再显示
又或者像状态，后端认为存的时候就查字典把 value 和 label 都存进去。

我是觉得存的时候可以存原始数据，在列表的时候后端查出来把相关内容转一遍直接返回给到前端。而不是值怎么存，怎么取。

label 显然是用户展示侧的东西，不应该由后端拼装。后端提供的接口数据需要考虑通用性，不一定能直接提供给前端使用，不过你可以让他提供一个字典接口，方便你进行拼装。

其实做不做都行的,

后台侧无所谓, 反正自己人用. 但是编辑数据的时候还是需要用原始状态配合状态字典, 除非你真的就用中文做值...

用户/客户端侧可以考虑格式化之后再返回, 可以避免部分业务状态被有心人猜到, 违规调用接口达成目的. (别杠什么鉴权, 很多时候真的就是能跑起来而已, 开发周期和 money 也不支持做得太完善...)

后端设计一定要考虑拓展性和通用性，比如今天 0 表示未使用，明天产品想要改成待使用，甚至想要做多语言版本，你每次更新都要改数据库的数据？

我们针对这种处理是分端的，针对客户端 后端的工作量比较大，基本上所有的数据都是处理好之后返回，客户端基本不做业务上的转换。针对 web 就比较糙了，基本都是让前端去处理

后端给的数据要简洁通用适配不同端比如 web 比如 app 比如小程序,如果多端无差异那么统一后端处理,如果多端有差异就不同端自行转换

我们是前端再去查字典展示

你不想搞 就让后端返回现成的，这东西要是后面改了，前端也不要发版。要么就是他给 key + 字典  你自己取，反正不要把 label 定义在前端。 到时候要改 两边都要改。正常 就是 key + 字典 你来处理。 其实后端直接返回也没啥。

让后端同时返回 status 和 statusName 就好了

你这个疑问，其实就是 bff 层出现的意义，哈哈