问一下后端的同学为何你们传参都喜欢 int 1234

应该这样写

{"code":"✓","mesg":"发送成功"}
{"code":"✘","mesg":"发送失败"}

手动滑稽

1.规避传参等字符编码问题
2.方便兼容和后续改动，名字可能修改，但数字没有实际意义 （如 麦当劳 ->金拱门）
3.数据库设计考虑 int 更节省内存 性能好 索引效率更高
4.部分语言不支持字符串 switch-case
感觉各有各的好处吧。

@tantalu 这个确实头疼，后端数据多个空格多个回车以为自己布局 bug

@mostkia 蛤蛤

🐱：淘宝
🐶：京东
🐮：拼多多

你们前端是不会用 enum 吗

字符串的编码、拼写错误、大小写问题都比数字多啊。

从头到尾没看到个好答案。都水过去了，可惜

@revalue 准确的说没有你想要的答案。我就觉得他们说得在理。不过也是分情况的，返回字符串主要是方便展示，存储肯定是 int 方便，如果字符串万年不改，前端去 map 也无所谓

@revalue 我觉得 102l 楼说的差不多了.

@yingo #110 102 楼

你们大多数设计出来的系统寿命都用不到拼多多改成拼夕夕的时候。
这种臆想出来的需求是自己给自己加戏。

你们写代码不用枚举的?

数字+数据字典

1 是给机器看的 淘宝是给人看的 建议搞下后端 一下子就明白了

……anti corruption layer 了解一下，像什么淘宝改名，本来就是应该在这一层解决的事情，而且不同子系统之间对数据模型的关注点不一样很正常……

@icylogic #116

哈哈哈就是这词，上次在 json 那讨论贴看到忘了

@imlinhanchao 问题是用个列表就解决了……

要我来设计可能会设计成 1,2,4,8,16
还能表达淘宝+拼多多--->1|2
算是被 C/C++给荼毒了吧，见不得额外开销

你这都喜欢就是要干翻一船人的节奏呀，一大堆魔术值真的优雅吗？，enum 出了对外提供多套接口可能有客户端反序列化失败的情况，并没有其他大坑得，数据库查询效率的确存在，如果存在这样问题再想办法也来的急吧，况且代码是给人看的，数据库的字典表难道就不需要维护吗？我是不是随便基于某个类型的数据统计下，还要翻下码表。程序何苦难为程序员吗