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

[en20]

比如接口要传一个请求来源,后端让我传的参是 1 拼多多, 2 淘宝, 3 京东 。。。

为什么不能直接给一个字符串 '淘宝',反正都是要 switch case ,这样也很直观.接手别人的项目里一堆 1234 我都不知道传的是什么,也不写个 map,我很难受

[AppxLite]

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

[zjsxwc]

因为数字简吧，

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

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

[otakustay]

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

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

[lldld]

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

[join]

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

[xuanbg]

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

[hazardous]

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

[zhangyangkam1]

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

[GopherTT]

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

[wingoo]

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

[hoyixi]

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

[hejw19970413]

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

[Chingim]

讨论的是接口, 接口是给人看的, 给人看的就要注重语义.
至于数据库的存储 , 你存 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

[Chingim]

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

[LennieChoi]

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

[MeteorCat]

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

[as94boy]

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

[MeteorCat]

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

[MeteorCat]

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

[min]

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