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

@Dogergo 个人感觉字符串才是比数字是更优雅的设计，尤其是当在你通过 SQL 维护或者统计数据的时候，直接就能看明白结果。
使用 int 的“优点”是在数据库存储上会有些微的节省空间以及性能优势，比如 MySQL 中可以用 tinyint 替代 varchar 。但是这是在以前存储很值钱的时候有点价值，现在对于普通 web 应用这点优势完全不值得牺牲可读性跟可维护性。

byte 枚举省带宽。属于强迫症。

用 int 比较方便，只要做好注释就没问题了

接口报文肯定是要留文档的 说明 1 代表什么 2 代表什么 不然别人接手肯定是一脸茫然

Python 无所谓，可读性高就行，一般习惯英文字符串

枚举

习惯了，在学校也是这样教的

一般用用-1，0，1，同时加注释说明代表的是什么，传字符串很容易遇到编码的问题

拼音就行，代码是写给人看的。
就这么几个字符串，数据库性能能有多少影响？

减少网络传输流量，降低用电量，低碳的 api 协议，绿色地球，从我做起（比心）

传数字的后果是加一层解释这些数字的逻辑，好处是需要的时候可以把这层逻辑改掉换成别的。。

传字符串的好处是前端觉得方便，后果是业务逻辑代码和字符串处理代码高度耦合，写出一堆 x 一样的代码，日后难以维护

这就体现出来 proto buf 的好处了

拼音 /英文是最佳方案，可读性强不容易看错，至于流量和性能的影响在当前的环境下几乎可以认为是 0 了，除非是极度苛刻的通信场景

还是以前学 C 语言遗留下来的习惯
前面说怕不兼容，主要也是因为这些年 UTF-8 一路发展过来，以前的语言对中文支持没那么好，而且有还有 windows 的一直是 ，windows xp 坚挺了这么多年，好像 win8 开始才统一 utf-8，处理编码很麻烦

但是现在用中文没毛病了，特别是现在的 java，php，golang，python3，都对 utf-8 支持很好了

拼多多改为了拼夕夕，你前后端都要改动？

以 java 来说。

1 、(重点原因) 数据库设计的范式、老师讲课的内容，教我们的就是尽量降低时间复杂度和空间复杂度。
int 能存的数据不要用 bigint，vchar(10)够用就不要用 vchar(200)。

因此在设计数据库（我不知道现在还有几家公司是有专门的数据库设计人员参与开发的，反正我见到的都是程序开发自己设计表）的字段时我们的就是使用 int byte char 之类的长度较小的字段存储这类枚举值的，只会在注释里写一下每个枚举对应的解释。 也因此会习惯性的将接口也设计成直接传这个枚举值。
如果传字符串也不是不可以，后端自己 switch case 一下传过来的字符串，将他们转成对应的枚举值就行了，就是要是添加了新值的话，那后端程序每个传这个数据的接口都得更新一遍 switch case，麻烦。

2 、jdk7 才支持 switch （ string ）， 但历史惯性让我们更习惯于使用 int 。
并且在懒得自己做压测、不知道 jdk 对 string 优化到什么程度的情况下，一般的 javaer 会自然的认为 switch case 一个 int 、char 和 enum 的性能是高于字符串的。

如果用字符串的话，你可能又要问了，为什么要用“taobao"不用”淘宝"?
这些都小事

经常更新扩展渠道的话，应该是这么做的，比如一些内部相应 code 都是约定用数字表达的，和 http 的 404，502 一样，和文字解耦，体积变小，方便归类

传数字正常操作，不要在后端出现 magic num 就好～

没有别的原因，就是因为 low

枚举值存库用数值型，除了带有顺序属性的枚举类型可能有排序的需要之后，真的比存字符串 low

而且即便存库用数值型，前后端接口用字符串也是没问题的，就是有的人不知道怎么处理

传字符串觉得好的，是不是恨不得在 Java 里也用中文类名啊？

这儿可能是淘宝 京东，假如之前的麦当劳变成了金拱门是不是得把代码里面的全局替换一次？

可以问后端把数据库地址要过来，数据库设计的时候 针对 1234 这样的应该都会有注释的，这样就都明白了，就算后端改了，你也一样能看到。
当然也可以让后端弄一份常量字典文档，但是后端可能比较不喜欢维护这个文档，或者忘记更新。

我记得在 V 站看过一个回答，

讨论是是 json 的的格式问题，
在这里也是适用的。

大概就是前端做一个 mapping 或者之类，防止代码被腐蚀恶臭。

@icyalala #46

这样的杠法，
是不是恨不得直接用 01 写代码啊？

不过某种程度讲，这个问题讨论不出结果，
大部分这种属于规范和建议性的东西，很难全部人遵循。

赞同 41 层，特别是以 c/c++入门的同学，很容易第一反应考虑时空复杂度

因为后端是枚举类型
enum Type {
PDD,
TAOBAO
}

1234 是程序自动出来的啊

我还是习惯用 1 2 表示

诸如 HTTP 协议，也用状态码 200 来判断是否成功，而不是通过字符串 OK 。很大程度上是因为数字比字符串更容易处理。另一方面数字的扩展性更好，要增加新的状态码，直接+1 就好，而字符串每次都要新想一个，还要担心是否与之前重复。当枚举量大的时候用字符串来处理其实是非常可怕的。

另外数字也有一些处理上的便利，比如要判断客户端上传的数据是否有效，直接 input>1 && input <=3 就好。

现在一般不在乎那么一点性能，但字符串的匹配确实没有数字的匹配快。

过早优化是万恶之源

@risent 赞同，很多时候，就行数据库字段有时直接 bigint 或者 int 就可以，不必要追求 int(1), tinyint 。 讲到用数字来代表实际含义的话，还要背枚举表，拉低效率。

字符串匹配比不上数字快，而且字符串存的长。但是我想一般只有对成本或者功耗有严苛要求的嵌入式开发者才会真正需要考虑这些

万一哪天“淘宝”变敏感词了呢[手动狗头]

无论是数字还是字符串，前端和后端都应该用常量来存。比如
const Taobao=1 或者 const Taobao="taobao"。
那么你在用的时候是用 Taobao，根本不用在乎他是数字还是字符串。那些纠结这个问题的人是不是在所有地方都写一遍“taobao”。

如果直观是判断设计好坏的唯一标准，那都应该去写易语言。

主要是方便数据库设计，万一哪天京东改名奶茶 呢？是不是要跑一遍数据库改为奶茶？拓展上更方便吧

因为数字简吧，

不谈中文字符串有 GBK 、 、Unicode
单单 Unicode 中 utf8 自身也分为码位与码元，因为编码缘故读取和传输存储的二进制是不一样的，

软件工程里面一个理念一直都是够用就行，既然数字能够满足需求了，为什么要用字符串这种过早的优化呢？

1. 语言层面上原生有 enum，没成本
2. 进数据库索引效率是数字高很多
3. 存储空间小很多
4. 如果 Web 层是字符串，服务层是数字，转换工作就在后端了麻烦

归根结底，enum 本来是个好实践，是人类自然语言到机器语言的映射手段，前端缺这个就想办法建这个完事，不应该为此去破坏机器语言的高效性

对于后端而言，字符串 taobao 比数字 1 的唯一优势就是好记，而这个可以用枚举解决; 但是其他诸如存储空间，查询匹配速度，范围选择等等所有方面都是数字更佳。

你如果把 taobao 拼成 taobo 或者 tobao 怎么办？
为什么 http 的状态码要用一个数字？
是因为为了解析协议方便，数字有唯一的映射，而且不会出错，没有二意性。

如果只是存起来看看的，字符串自然是极好的。但如果参与业务逻辑的话，有的传「淘宝」，有的传「淘」，你就要疯掉了。。。

1 转换成淘宝很简单，淘宝转换成 1 很麻烦

来个 enum 不就好了，除非你们后端不写接口文档？

如 @miniwade514 @guogang9011 所说，这个东西依赖后端提供的文档，无脑加一，前后端都要维护一份常量映射，如果有的地方用到的常量映射较多，可以让后端给个接口也未尝不可

文字等容易变动的地方最好有中转, 特别是对于 app 等更新比较麻烦的
正常的做法, 给你的时候就是 id,name 对应值, name 用于展示, id 用于同后端的交互

便于修改，只改后台代码，接口不用改，前端也就不用动了

如果是现在的话，传什么都可以，传 int 是以前留下的习惯。

讨论的是接口, 接口是给人看的, 给人看的就要注重语义.
至于数据库的存储 , 你存 1/2/3, 再开一张表存 123 和 taobao/jd 的对应关系都行, 都是你的内部实现.

接口语义化方便前端 /后端 /测试更好地理解传输的数据内容, 看日志 /抓包的时候
- taobao/jingdong 比 1/2 更清楚
- male/female 比 1/2 更清楚
- '2019-11-17T17:43:43Z ' 比 1589528379 更清楚


比如 github 的 API ( https://developer.github.com/v3/pulls/reviews/) 是可读性良好的典范, 枚举类型它能用字符串他是不会用 1/2/3 的, 时间戳也是人类友好的 0 时区

https://tva1.sinaimg.cn/large/007S8ZIlgy1get6j4trhlj30u010snfl.jpg

你们的业务有多少能比 github 的体量大?

毕竟程序是和一堆数字打交道的，做成枚举的好处是好分类，比如一个商家上了拼多多又上了京东，我做一个掩码存这个状态，然后只需在众多商家中 查找 掩码二进制位 101 的商家就可以了，多香

后台入库统计咋办？字符串存筛选？

@hhyvs111 赞同，大部分都是感觉没有逼格。

我见过一些拼音入库字段，比如今天有个来源 TB 叫淘宝，以后有个叫淘贝，后天有个叫套包，是不是都要叫 tb/taobao/tb123，

@MeteorCat 还有不少默认数据库 MySQL5.x 的，入库有中文都有乱码问题

都是年轻程序员，我等老鸟一般传“锟斤拷锟斤拷锟斤拷”的

1 => taobao_deprecated_1; 5 => taobao
OR
'taobao' 'taobao_new‘ ’taobao_really_new' 'taobao_really_realy_new'

难道大家不都是这样，哈哈。。。

看技术栈和团队情况吧，我们用的技术栈都是对 Unicode 兼容性特别好的，以高可读性作为首要要求，所以会直接传全文。

那换成 4321 可以吗

用数据字典 可扩展性更强

@namelosw 那是了做值并列，比如同具 1 和 2 。那麽就是 1 | 2 = 3 。 查的候就是 3 & 1 = 1，3 & 4 = 0 。就知道有 1 4 。

拼多多改成了拼夕夕 你要全改一边？

经典问题了

这也能喷？

宏定义吧，高效啊，

其实传什么都行，反正要约定好就行

我投语义化一票

约定和文档是会随着时间腐烂的，最好的办法就是明确意义，也就是使用 string 。代码即注释是质量的底线，

这个是什么设定，enter 一下就提交了 0.0，哎
enter 了也没有提交，难道是 shift + enter 直接提交

破案了，Ctrl enter

其实只要不是中文编码，都可以，中文编码的坑太多了

如果后端是我……前面传“淘宝|京东|拼多多”或者“1|2|3|4”我都接

首先接口文档里面明确，传字符串和传数据字典指针都可以
其次错误提示里面要清楚的说明“您传递的‘拼夕夕’这个参数不在合法的输入值范围内”

至于数据库如何如何，查询如何如何，今后如何如何，这本就不是去和前端争辩的事

@Wincer 那么，要如何反驳这个观点呢？

前端页面都建立映射了，又不是动态字典，真要有心爬取，根本不能拦住。况且平白损失可读性，加大了调试、排查难度？

这样能说服吗

我作为后端现在就是直接传的字符串，前端却问我为啥不传 1234

如果字符串参数里面有个不可见字符查问题能查一天。。。