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

楼主是觉得整数比较和字符串比较是一样的？

问这种问题的都不是专业程序员

动态类型搞字符串方便，如果后端是静态类型语言，enum 不香吗？
如果要前端显示出来的话，后端应当把要显示的值或映射传给前端

后端可能是 enum 一个字典集
code msg
0 xxx
1 xxx
只是没给你全部返回给你定义了要传 code 而已
如果换成把字典都返回给你 是否就没意见了

似乎希望语义化的都是前端，希望使用数字枚举的多数是后端
其实无非一个把枚举到语义转换的操作放在哪儿的问题，设计上肯定要分开，我可不想将来某个枚举改个名字要去改一堆的代码
前端想要后端做好，我直接展示；后端觉得枚举有了，返给你 key 值你映射一下有什么难的嘛
其实，对于一个量级比较大的服务，夸张点以谷歌为例，每天处理的空格的体积都非常大，如果返回去一堆汉字，那占用带宽更是大的多，前端 cache 一份枚举的缓存，针对枚举的字段客户端使用本地 cache 直接转换不挺好么
另外，如果这个枚举在客户端有需要处理的业务逻辑，到处 switch 或者 if 淘宝、京东，不觉得很 low 么？反正如果后端用这样的枚举如果看到绝壁要骂人的
这样涉及到不同环境，多个语言等情况，比较原始的类型比较安全，基本能始终保证统一，英文字符串也比汉字要强一些
最后，我是后端 🐶

退一步，我可以接受用 ["pinduoduo", "taobao","jd"]，但是不接受用中文。
因为一旦用了中文，就没有什么阻止前端直接拿它用来展示了。
而一个会拿枚举类型直接展示的前端，将来一定会在拼多多改名的时候来要求后端也改名的。

@ipwx 这还真不好说，好多人都不知道 360buy 是谁

这种问题都能拉两页

@ipwx #12 这不是认不认识的问题。假如发生改名问题，你系统里还显示老名字，你的客户会同意吗？你老板会同意吗？

@ilaipi 骚年，这个名字（我假设是英文或者拼音）只是为了取代数字枚举，让开发人员开发的时候不至于每次都要查手册。本质还是个枚举，不能直接显示的。。。 就像 @binux 说的那样。

前端无论如何都应该自己翻译后端过来的名字。。。

@namelosw 我就是那个用 0 、1 、2 、4 模仿 linux 权限的人😏
我们用一个状态码表示一个用户拥有多种权限

带宽占用啊，这一项就相差非常多了。这都不做优化？

@revalue 二楼说得挺好的，不是么

@namelosw 因为在数据库存一个数字比存列表简单。

@imlinhanchao 感觉这个算偷懒，多加个表关联就行了……

@namelosw 加表性能上就差了。不過確實這種方法其實在嵌入式上應用比較多。

做为一个后端，你要是能数据库是 int，对外接口是 string，只能说你很不一般