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

淘宝

int

Switch

map

138 条回复 • 2020-06-08 11:40:48 +08:00

1 2

❮

❯

1

murmur

2020-05-15 11:31:38 +08:00

3

c 和老 java 年代留下来的习惯，手动定义一堆常量，没让你传 1248 就很给面子了

你要知道一些老的标准 switch case 不支持 string 的

2

hhyvs111

2020-05-15 11:32:25 +08:00

中文字符串也太 low 了吧，传个拼音或者缩写可以理解

3

Lin0936

2020-05-15 11:33:30 +08:00

可能是 enum

4

gamexg

2020-05-15 11:34:19 +08:00 via Android

如 1 楼，老习惯，定义常量然后使用。

如果真的不希望使用数字，那么推荐字母。非常不推荐中文，中文有时会出现编码问题。

5

en20

OP

2020-05-15 11:35:25 +08:00

后端是 php,问了一下同事说传字符串他们领导会骂他

6

KyonLi

2020-05-15 11:35:46 +08:00

22

还可以传 emoji

7

Wincer

2020-05-15 11:37:21 +08:00 via Android

11

要是前端这么问我，我就会说这是为了安全起见，隐藏真实的数据来源和含义 🐶

8

hbolive

2020-05-15 11:38:25 +08:00

1

传 int 可能还有数据库设计上的考虑，enum/int 这些，在统计上效率明显高于 string

9

hallDrawnel

2020-05-15 11:40:25 +08:00

电商名字感觉拼音缩写比较 ok，后期不够了还可以用全名。数字也不是不行，但是必须约定一个固定映射，不能随便改动。后端甚至可以给前端出一段代码获取这些映射名字，很简单的。（我就是后端我是愿意的，估计他们不愿意）

10

Dogergo

2020-05-15 11:41:05 +08:00

赞同楼上，是为了数据库设计更优，存字符的话会有很多不便。我们代码里一般会有对应的数据字典[1=>'淘宝'],这样淘宝将来改名字了，我们只用修改代码，而不是更新掉数据。

11

catror

2020-05-15 11:42:20 +08:00 via Android

偷懒而已，省一道转换

12

ipwx

2020-05-15 11:42:52 +08:00

@Dogergo 都只是个代号，电商改名字你并不需要改常量啊。。。这么大的电商，就算改个名字，叫老名字十年内大家都还记得的吧。

13

Mutoo

2020-05-15 11:42:54 +08:00

3

跟后端要一份常量字典文档，problem solved ✅️

14

fancy111

2020-05-15 11:44:25 +08:00

不是喜欢用，是方便而已。
你什么都可以传啊，因为 get/post 也是可以都传的。中文有时候会遇到编码问题，而且不建议带特殊字符，所以综合来说数字和字母最好。

15

Chingim

2020-05-15 11:46:40 +08:00 via Android

@Dogergo 接口字段没必要和数据字段等同呀，毕竟接口是给人看的。看日志的时候一堆 1234 不是效率较低吗

也可以再起一个表来存 1234 和 taobao/jd 的关系嘛

16

miniwade514

2020-05-15 11:46:46 +08:00

用数字枚举的好处，需要增加新值的时候，只要无脑 +1 。坏处，传到前端就没有语义了，依赖文档。如果随着业务迭代需要经常新增，文档更新还不及时，就很烦了。

17

qwerthhusn

2020-05-15 11:47:20 +08:00

说一下 java 和 MySQL
jdk7 之前是不支持 switch 字符串的
但是可以用 enum

enum 的话，数据库就有问题了，映射成字符串的话，查询时字符串查询肯定比数字要慢（不要说索引，这种就几个值的分布全表，建了索引也没用），mysql 也支持 enum，但是如果要新增删除项，就不像 java 那么简单了

18

chairuosen

2020-05-15 11:49:00 +08:00

6

并不是偷懒，淘宝要是改名成马云宝呢？你要手动刷一遍库么？

19

namelosw

2020-05-15 11:51:34 +08:00

1

前后端都写的感觉还是字符串好。

不过 1 2 3 4 都是小儿科，我还见过跟 Linux 权限一样那种 0 1 2 4 加到 7 那种用来表示列表……

20

yousabuk

2020-05-15 11:53:05 +08:00

传数字好兼容，好扩展，好修改，因为数字本身不代表任何含义。跨语言就更麻烦了，会制造无谓的 BUG 。

1，传中文：字符编码兼容问题，1 个中文占 2 个字节；
2，传拼音或者英文：也势必比 int 型占用的字节多，；
3，堆栈的区别（ Java ）；
4，利于内存管理：如果是 0~7 就完全够用，那么后端可以定义数据类型为：u8, byte, char 等，节省内存。如果是嵌入式设备就有必要。
5，某些语言不支持字符串 Switch ；

弊端太多了。

21

sagaxu

2020-05-15 11:55:20 +08:00 via Android

代码中不应该出现 ascii 以外的字符，传中文还得写成 unicode

22

huntcool001

2020-05-15 11:55:51 +08:00

主要是映射到 mysql 数据库里方便些. 我们是数据库里不允许用 enum 的.

23

dongisking

2020-05-15 11:57:50 +08:00

传中文改名字了怎么办？字符兼容性问题怎么搞？
传 taobao，pdd，jd 还不是得要注释一下

24

Mithril

2020-05-15 11:57:58 +08:00

传 enum 就会被改成 int，所以说直接上 GraphQL 就好了，enum 会自动转换。

25

shimmerh

2020-05-15 11:58:36 +08:00

如果类型少就用 int 代表就好了，类型太多还是用字母代号

26

risent

2020-05-15 11:59:32 +08:00

11

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

27

shatuo

2020-05-15 12:08:11 +08:00

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

28

kof21411

2020-05-15 12:08:56 +08:00

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

29

W1angMh

2020-05-15 12:12:02 +08:00 via iPhone

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

30

TypeError

2020-05-15 12:15:02 +08:00 via Android

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

31

opengps

2020-05-15 12:24:01 +08:00 via Android

枚举

32

Cielsky

2020-05-15 12:26:24 +08:00

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

33

Suaxi

2020-05-15 12:27:04 +08:00 via iPhone

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

34

jiyingze

2020-05-15 12:34:30 +08:00 via iPhone

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

35

kisshere

2020-05-15 12:41:07 +08:00

2

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

36

lechain

2020-05-15 12:43:41 +08:00 via Android

1

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

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

37

leishi1313

2020-05-15 12:44:09 +08:00 via Android

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

38

rekulas

2020-05-15 12:47:39 +08:00

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

39

liuxu

2020-05-15 12:57:37 +08:00

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

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

40

bk201

2020-05-15 13:00:47 +08:00

2

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

41

zpf124

2020-05-15 13:03:43 +08:00

1

以 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 的性能是高于字符串的。

42

darknoll

2020-05-15 13:07:40 +08:00

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

43

ZehaiZhang

2020-05-15 13:09:50 +08:00

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

44

SjwNo1

2020-05-15 13:11:53 +08:00

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

45

lululau

2020-05-15 13:13:50 +08:00

1

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

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

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

46

icyalala

2020-05-15 13:17:34 +08:00

1

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

47

JRay

2020-05-15 13:37:47 +08:00

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

48

guogang9011

2020-05-15 13:38:06 +08:00

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

49

freakxx

2020-05-15 13:44:41 +08:00

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

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

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

50

freakxx

2020-05-15 13:45:54 +08:00

4

@icyalala #46

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

51

freakxx

2020-05-15 13:49:08 +08:00

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

52

ershierdu

2020-05-15 13:49:24 +08:00 via iPhone

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

53

zhuweiyou

2020-05-15 13:53:47 +08:00

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

1234 是程序自动出来的啊

54

fiypig

2020-05-15 14:15:31 +08:00

我还是习惯用 1 2 表示

55

AngryMagikarp

2020-05-15 14:19:36 +08:00

2

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

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

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

56

crella

2020-05-15 14:21:42 +08:00 via Android

过早优化是万恶之源

57

qW7bo2FbzbC0

2020-05-15 14:21:45 +08:00

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

58

qW7bo2FbzbC0

2020-05-15 14:23:30 +08:00

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

59

awfe

2020-05-15 14:23:55 +08:00

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

60

AngryMagikarp

2020-05-15 14:29:09 +08:00

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

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

61

AppxLite

2020-05-15 14:35:05 +08:00

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

62

zjsxwc

2020-05-15 14:38:27 +08:00

因为数字简吧，

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

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

63

otakustay

2020-05-15 14:42:00 +08:00

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

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

64

lldld

2020-05-15 14:44:53 +08:00 via iPhone

1

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

65

join

2020-05-15 14:46:27 +08:00

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

66

xuanbg

2020-05-15 14:46:52 +08:00

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

67

hazardous

2020-05-15 14:47:07 +08:00

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

68

zhangyangkam1

2020-05-15 14:47:27 +08:00

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

69

GopherTT

2020-05-15 14:49:40 +08:00

1

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

70

wingoo

2020-05-15 14:49:50 +08:00

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

71

hoyixi

2020-05-15 14:54:05 +08:00

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

72

hejw19970413

2020-05-15 15:42:49 +08:00

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

73

Chingim

2020-05-15 15:44:44 +08:00

8

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

74

Chingim

2020-05-15 15:47:32 +08:00

2

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