V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
en20
V2EX  ›  程序员

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

  •  
  •   en20 ·
    vuejs · 2020-05-15 11:29:37 +08:00 · 15256 次点击
    这是一个创建于 739 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    138 条回复    2020-06-08 11:40:48 +08:00
    1  2  
    murmur
        1
    murmur  
       2020-05-15 11:31:38 +08:00   ❤️ 3
    c 和老 java 年代留下来的习惯,手动定义一堆常量,没让你传 1248 就很给面子了

    你要知道一些老的标准 switch case 不支持 string 的
    hhyvs111
        2
    hhyvs111  
       2020-05-15 11:32:25 +08:00
    中文字符串也太 low 了吧,传个拼音或者缩写可以理解
    Lin0936
        3
    Lin0936  
       2020-05-15 11:33:30 +08:00
    可能是 enum
    gamexg
        4
    gamexg  
       2020-05-15 11:34:19 +08:00 via Android
    如 1 楼,老习惯,定义常量然后使用。

    如果真的不希望使用数字,那么推荐字母。非常不推荐中文,中文有时会出现编码问题。
    en20
        5
    en20  
    OP
       2020-05-15 11:35:25 +08:00
    后端是 php,问了一下同事说传字符串他们领导会骂他
    KyonLi
        6
    KyonLi  
       2020-05-15 11:35:46 +08:00   ❤️ 21
    还可以传 emoji
    Wincer
        7
    Wincer  
       2020-05-15 11:37:21 +08:00 via Android   ❤️ 11
    要是前端这么问我,我就会说这是为了安全起见,隐藏真实的数据来源和含义 🐶
    hbolive
        8
    hbolive  
       2020-05-15 11:38:25 +08:00   ❤️ 1
    传 int 可能还有数据库设计上的考虑,enum/int 这些,在统计上效率明显高于 string
    hallDrawnel
        9
    hallDrawnel  
       2020-05-15 11:40:25 +08:00
    电商名字感觉拼音缩写比较 ok,后期不够了还可以用全名。数字也不是不行,但是必须约定一个固定映射,不能随便改动。后端甚至可以给前端出一段代码获取这些映射名字,很简单的。(我就是后端我是愿意的,估计他们不愿意)
    Dogergo
        10
    Dogergo  
       2020-05-15 11:41:05 +08:00
    赞同楼上,是为了数据库设计更优,存字符的话会有很多不便。我们代码里一般会有对应的数据字典[1=>'淘宝'],这样淘宝将来改名字了,我们只用修改代码,而不是更新掉数据。
    catror
        11
    catror  
       2020-05-15 11:42:20 +08:00 via Android
    偷懒而已,省一道转换
    ipwx
        12
    ipwx  
       2020-05-15 11:42:52 +08:00
    @Dogergo 都只是个代号,电商改名字你并不需要改常量啊。。。这么大的电商,就算改个名字,叫老名字十年内大家都还记得的吧。
    Mutoo
        13
    Mutoo  
       2020-05-15 11:42:54 +08:00   ❤️ 3
    跟后端要一份常量字典文档,problem solved ✅️
    fancy111
        14
    fancy111  
       2020-05-15 11:44:25 +08:00
    不是喜欢用,是方便而已。
    你什么都可以传啊,因为 get/post 也是可以都传的。中文有时候会遇到编码问题,而且不建议带特殊字符,所以综合来说数字和字母最好。
    Chingim
        15
    Chingim  
       2020-05-15 11:46:40 +08:00 via Android
    @Dogergo 接口字段没必要和数据字段等同呀,毕竟接口是给人看的。看日志的时候一堆 1234 不是效率较低吗

    也可以再起一个表来存 1234 和 taobao/jd 的关系嘛
    miniwade514
        16
    miniwade514  
       2020-05-15 11:46:46 +08:00
    用数字枚举的好处,需要增加新值的时候,只要无脑 +1 。坏处,传到前端就没有语义了,依赖文档。如果随着业务迭代需要经常新增,文档更新还不及时,就很烦了。
    qwerthhusn
        17
    qwerthhusn  
       2020-05-15 11:47:20 +08:00
    说一下 java 和 MySQL
    jdk7 之前是不支持 switch 字符串的
    但是可以用 enum

    enum 的话,数据库就有问题了,映射成字符串的话,查询时字符串查询肯定比数字要慢(不要说索引,这种就几个值的分布全表,建了索引也没用),mysql 也支持 enum,但是如果要新增删除项,就不像 java 那么简单了
    chairuosen
        18
    chairuosen  
       2020-05-15 11:49:00 +08:00   ❤️ 6
    并不是偷懒,淘宝要是改名成马云宝呢?你要手动刷一遍库么?
    namelosw
        19
    namelosw  
       2020-05-15 11:51:34 +08:00   ❤️ 1
    前后端都写的感觉还是字符串好。

    不过 1 2 3 4 都是小儿科,我还见过跟 Linux 权限一样那种 0 1 2 4 加到 7 那种用来表示列表……
    yousabuk
        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 ;

    弊端太多了。
    sagaxu
        21
    sagaxu  
       2020-05-15 11:55:20 +08:00 via Android
    代码中不应该出现 ascii 以外的字符,传中文还得写成 unicode
    huntcool001
        22
    huntcool001  
       2020-05-15 11:55:51 +08:00
    主要是映射到 mysql 数据库里方便些. 我们是数据库里不允许用 enum 的.
    dongisking
        23
    dongisking  
       2020-05-15 11:57:50 +08:00
    传中文改名字了怎么办?字符兼容性问题怎么搞?
    传 taobao,pdd,jd 还不是得要注释一下
    Mithril
        24
    Mithril  
       2020-05-15 11:57:58 +08:00
    传 enum 就会被改成 int,所以说直接上 GraphQL 就好了,enum 会自动转换。
    shimmerh
        25
    shimmerh  
       2020-05-15 11:58:36 +08:00
    如果类型少就用 int 代表就好了,类型太多还是用字母代号
    risent
        26
    risent  
       2020-05-15 11:59:32 +08:00   ❤️ 11
    @Dogergo 个人感觉字符串才是比数字是更优雅的设计,尤其是当在你通过 SQL 维护或者统计数据的时候,直接就能看明白结果。
    使用 int 的“优点”是在数据库存储上会有些微的节省空间以及性能优势,比如 MySQL 中可以用 tinyint 替代 varchar 。但是这是在以前存储很值钱的时候有点价值,现在对于普通 web 应用这点优势完全不值得牺牲可读性跟可维护性。
    shatuo
        27
    shatuo  
       2020-05-15 12:08:11 +08:00
    byte 枚举省带宽。属于强迫症。
    kof21411
        28
    kof21411  
       2020-05-15 12:08:56 +08:00
    用 int 比较方便,只要做好注释就没问题了
    W1angMh
        29
    W1angMh  
       2020-05-15 12:12:02 +08:00 via iPhone
    接口报文肯定是要留文档的 说明 1 代表什么 2 代表什么 不然别人接手肯定是一脸茫然
    TypeError
        30
    TypeError  
       2020-05-15 12:15:02 +08:00 via Android
    Python 无所谓,可读性高就行,一般习惯英文字符串
    opengps
        31
    opengps  
       2020-05-15 12:24:01 +08:00 via Android
    枚举
    Cielsky
        32
    Cielsky  
       2020-05-15 12:26:24 +08:00
    习惯了,在学校也是这样教的
    Suaxi
        33
    Suaxi  
       2020-05-15 12:27:04 +08:00 via iPhone
    一般用用-1,0,1,同时加注释说明代表的是什么,传字符串很容易遇到编码的问题
    jiyingze
        34
    jiyingze  
       2020-05-15 12:34:30 +08:00 via iPhone
    拼音就行,代码是写给人看的。
    就这么几个字符串,数据库性能能有多少影响?
    kisshere
        35
    kisshere  
       2020-05-15 12:41:07 +08:00   ❤️ 2
    减少网络传输流量,降低用电量,低碳的 api 协议,绿色地球,从我做起(比心)
    lechain
        36
    lechain  
       2020-05-15 12:43:41 +08:00 via Android   ❤️ 1
    传数字的后果是加一层解释这些数字的逻辑,好处是需要的时候可以把这层逻辑改掉换成别的。。

    传字符串的好处是前端觉得方便,后果是业务逻辑代码和字符串处理代码高度耦合,写出一堆 x 一样的代码,日后难以维护
    leishi1313
        37
    leishi1313  
       2020-05-15 12:44:09 +08:00 via Android
    这就体现出来 proto buf 的好处了
    rekulas
        38
    rekulas  
       2020-05-15 12:47:39 +08:00
    拼音 /英文是最佳方案,可读性强不容易看错,至于流量和性能的影响在当前的环境下几乎可以认为是 0 了,除非是极度苛刻的通信场景
    liuxu
        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 支持很好了
    bk201
        40
    bk201  
       2020-05-15 13:00:47 +08:00   ❤️ 2
    拼多多改为了拼夕夕,你前后端都要改动?
    zpf124
        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 的性能是高于字符串的。
    darknoll
        42
    darknoll  
       2020-05-15 13:07:40 +08:00
    如果用字符串的话,你可能又要问了,为什么要用“taobao"不用”淘宝"?
    这些都小事
    ZehaiZhang
        43
    ZehaiZhang  
       2020-05-15 13:09:50 +08:00
    经常更新扩展渠道的话,应该是这么做的,比如一些内部相应 code 都是约定用数字表达的,和 http 的 404,502 一样,和文字解耦,体积变小,方便归类
    SjwNo1
        44
    SjwNo1  
       2020-05-15 13:11:53 +08:00
    传数字正常操作,不要在后端出现 magic num 就好~
    lululau
        45
    lululau  
       2020-05-15 13:13:50 +08:00   ❤️ 1
    没有别的原因,就是因为 low

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

    而且即便存库用数值型,前后端接口用字符串也是没问题的,就是有的人不知道怎么处理
    icyalala
        46
    icyalala  
       2020-05-15 13:17:34 +08:00   ❤️ 1
    传字符串觉得好的,是不是恨不得在 Java 里也用中文类名啊?
    JRay
        47
    JRay  
       2020-05-15 13:37:47 +08:00
    这儿可能是淘宝 京东,假如之前的麦当劳变成了金拱门是不是得把代码里面的全局替换一次?
    guogang9011
        48
    guogang9011  
       2020-05-15 13:38:06 +08:00
    可以问后端把数据库地址要过来,数据库设计的时候 针对 1234 这样的应该都会有注释的,这样就都明白了,就算后端改了,你也一样能看到。
    当然也可以让后端弄一份常量字典文档,但是后端可能比较不喜欢维护这个文档,或者忘记更新。
    freakxx
        49
    freakxx  
       2020-05-15 13:44:41 +08:00
    我记得在 V 站看过一个回答,

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

    大概就是前端做一个 mapping 或者之类,防止代码被腐蚀恶臭。
    freakxx
        50
    freakxx  
       2020-05-15 13:45:54 +08:00   ❤️ 4
    @icyalala #46

    这样的杠法,
    是不是恨不得直接用 01 写代码啊?
    freakxx
        51
    freakxx  
       2020-05-15 13:49:08 +08:00
    不过某种程度讲,这个问题讨论不出结果,
    大部分这种属于规范和建议性的东西,很难全部人遵循。
    ershierdu
        52
    ershierdu  
       2020-05-15 13:49:24 +08:00 via iPhone
    赞同 41 层,特别是以 c/c++入门的同学,很容易第一反应考虑时空复杂度
    zhuweiyou
        53
    zhuweiyou  
       2020-05-15 13:53:47 +08:00
    因为后端是枚举类型
    enum Type {
    PDD,
    TAOBAO
    }

    1234 是程序自动出来的啊
    fiypig
        54
    fiypig  
       2020-05-15 14:15:31 +08:00
    我还是习惯用 1 2 表示
    AngryMagikarp
        55
    AngryMagikarp  
       2020-05-15 14:19:36 +08:00   ❤️ 2
    诸如 HTTP 协议,也用状态码 200 来判断是否成功,而不是通过字符串 OK 。很大程度上是因为数字比字符串更容易处理。另一方面数字的扩展性更好,要增加新的状态码,直接+1 就好,而字符串每次都要新想一个,还要担心是否与之前重复。当枚举量大的时候用字符串来处理其实是非常可怕的。

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

    现在一般不在乎那么一点性能,但字符串的匹配确实没有数字的匹配快。
    crella
        56
    crella  
       2020-05-15 14:21:42 +08:00 via Android
    过早优化是万恶之源
    qW7bo2FbzbC0
        57
    qW7bo2FbzbC0  
       2020-05-15 14:21:45 +08:00
    @risent 赞同,很多时候,就行数据库字段有时直接 bigint 或者 int 就可以,不必要追求 int(1), tinyint 。 讲到用数字来代表实际含义的话,还要背枚举表,拉低效率。
    qW7bo2FbzbC0
        58
    qW7bo2FbzbC0  
       2020-05-15 14:23:30 +08:00
    字符串匹配比不上数字快,而且字符串存的长。但是我想一般只有对成本或者功耗有严苛要求的嵌入式开发者才会真正需要考虑这些
    awfe
        59
    awfe  
       2020-05-15 14:23:55 +08:00
    万一哪天“淘宝”变敏感词了呢[手动狗头]
    AngryMagikarp
        60
    AngryMagikarp  
       2020-05-15 14:29:09 +08:00
    无论是数字还是字符串,前端和后端都应该用常量来存。比如
    const Taobao=1 或者 const Taobao="taobao"。
    那么你在用的时候是用 Taobao,根本不用在乎他是数字还是字符串。那些纠结这个问题的人是不是在所有地方都写一遍“taobao”。

    如果直观是判断设计好坏的唯一标准,那都应该去写易语言。
    AppxLite
        61
    AppxLite  
       2020-05-15 14:35:05 +08:00
    主要是方便数据库设计,万一哪天京东改名奶茶 呢?是不是要跑一遍数据库改为奶茶?拓展上更方便吧
    zjsxwc
        62
    zjsxwc  
       2020-05-15 14:38:27 +08:00
    因为数字简吧,

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

    软件工程里面一个理念一直都是够用就行,既然数字能够满足需求了,为什么要用字符串这种过早的优化呢?
    otakustay
        63
    otakustay  
       2020-05-15 14:42:00 +08:00
    1. 语言层面上原生有 enum,没成本
    2. 进数据库索引效率是数字高很多
    3. 存储空间小很多
    4. 如果 Web 层是字符串,服务层是数字,转换工作就在后端了麻烦

    归根结底,enum 本来是个好实践,是人类自然语言到机器语言的映射手段,前端缺这个就想办法建这个完事,不应该为此去破坏机器语言的高效性
    lldld
        64
    lldld  
       2020-05-15 14:44:53 +08:00 via iPhone   ❤️ 1
    对于后端而言,字符串 taobao 比数字 1 的唯一优势就是好记,而这个可以用枚举解决; 但是其他诸如存储空间,查询匹配速度,范围选择等等所有方面都是数字更佳。
    join
        65
    join  
       2020-05-15 14:46:27 +08:00
    你如果把 taobao 拼成 taobo 或者 tobao 怎么办?
    为什么 http 的状态码要用一个数字?
    是因为为了解析协议方便,数字有唯一的映射,而且不会出错,没有二意性。
    xuanbg
        66
    xuanbg  
       2020-05-15 14:46:52 +08:00
    如果只是存起来看看的,字符串自然是极好的。但如果参与业务逻辑的话,有的传「淘宝」,有的传「淘寶」,你就要疯掉了。。。
    hazardous
        67
    hazardous  
       2020-05-15 14:47:07 +08:00
    1 转换成淘宝很简单,淘宝转换成 1 很麻烦
    zhangyangkam1
        68
    zhangyangkam1  
       2020-05-15 14:47:27 +08:00
    来个 enum 不就好了,除非你们后端不写接口文档?
    GopherTT
        69
    GopherTT  
       2020-05-15 14:49:40 +08:00   ❤️ 1
    如 @miniwade514 @guogang9011 所说,这个东西依赖后端提供的文档,无脑加一,前后端都要维护一份常量映射,如果有的地方用到的常量映射较多,可以让后端给个接口也未尝不可
    wingoo
        70
    wingoo  
       2020-05-15 14:49:50 +08:00
    文字等容易变动的地方最好有中转, 特别是对于 app 等更新比较麻烦的
    正常的做法, 给你的时候就是 id,name 对应值, name 用于展示, id 用于同后端的交互
    hoyixi
        71
    hoyixi  
       2020-05-15 14:54:05 +08:00
    便于修改,只改后台代码,接口不用改,前端也就不用动了
    hejw19970413
        72
    hejw19970413  
       2020-05-15 15:42:49 +08:00
    如果是现在的话,传什么都可以,传 int 是以前留下的习惯。
    Chingim
        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
    Chingim
        74
    Chingim  
       2020-05-15 15:47:32 +08:00   ❤️ 2
    你们的业务有多少能比 github 的体量大?
    LennieChoi
        75
    LennieChoi  
       2020-05-15 15:54:00 +08:00
    毕竟程序是和一堆数字打交道的,做成枚举的好处是好分类,比如一个商家上了拼多多又上了京东,我做一个掩码存这个状态,然后只需在众多商家中 查找 掩码二进制位 101 的商家就可以了,多香
    MeteorCat
        76
    MeteorCat  
       2020-05-15 15:54:07 +08:00 via Android
    后台入库统计咋办?字符串存筛选?
    as94boy
        77
    as94boy  
       2020-05-15 15:55:40 +08:00
    @hhyvs111 赞同,大部分都是感觉没有逼格。
    MeteorCat
        78
    MeteorCat  
       2020-05-15 15:59:34 +08:00 via Android
    我见过一些拼音入库字段,比如今天有个来源 TB 叫淘宝,以后有个叫淘贝,后天有个叫套包,是不是都要叫 tb/taobao/tb123,
    MeteorCat
        79
    MeteorCat  
       2020-05-15 16:00:28 +08:00 via Android
    @MeteorCat 还有不少默认数据库 MySQL5.x 的,入库有中文都有乱码问题
    min
        80
    min  
       2020-05-15 16:13:33 +08:00
    都是年轻程序员,我等老鸟一般传“锟斤拷锟斤拷锟斤拷”的
    cyspy
        81
    cyspy  
       2020-05-15 16:21:20 +08:00
    1 => taobao_deprecated_1; 5 => taobao
    OR
    'taobao' 'taobao_new‘ ’taobao_really_new' 'taobao_really_realy_new'
    Cowhitewhite
        82
    Cowhitewhite  
       2020-05-15 16:24:43 +08:00
    难道大家不都是这样,哈哈。。。
    libook
        83
    libook  
       2020-05-15 16:25:22 +08:00
    看技术栈和团队情况吧,我们用的技术栈都是对 Unicode 兼容性特别好的,以高可读性作为首要要求,所以会直接传全文。
    Arthit
        84
    Arthit  
       2020-05-15 16:26:25 +08:00   ❤️ 1
    那换成 4321 可以吗
    LYEHIZRF
        85
    LYEHIZRF  
       2020-05-15 16:31:48 +08:00
    用数据字典 可扩展性更强
    imlinhanchao
        86
    imlinhanchao  
       2020-05-15 16:31:48 +08:00
    @namelosw 那是爲了做值并列,比如同時具備 1 和 2 。那麽就是 1 | 2 = 3 。 檢查的時候就是 3 & 1 = 1,3 & 4 = 0 。這樣就知道有 1 沒 4 。
    sanqian
        87
    sanqian  
       2020-05-15 16:32:18 +08:00
    拼多多改成了拼夕夕 你要全改一边?
    vincentxue
        88
    vincentxue  
       2020-05-15 16:33:18 +08:00
    经典问题了
    ming7435
        89
    ming7435  
       2020-05-15 16:34:31 +08:00
    这也能喷?
    hu8245
        90
    hu8245  
       2020-05-15 16:41:44 +08:00
    宏定义吧,高效啊,
    XGF
        91
    XGF  
       2020-05-15 16:43:28 +08:00
    其实传什么都行,反正要约定好就行
    misaka19000
        92
    misaka19000  
       2020-05-15 16:45:48 +08:00   ❤️ 1
    我投语义化一票
    atwoodSoInterest
        93
    atwoodSoInterest  
       2020-05-15 16:47:39 +08:00   ❤️ 3
    约定和文档是会随着时间腐烂的,最好的办法就是明确意义,也就是使用 string 。代码即注释是质量的底线,
    atwoodSoInterest
        94
    atwoodSoInterest  
       2020-05-15 16:49:10 +08:00
    这个是什么设定,enter 一下就提交了 0.0,哎
    enter 了也没有提交,难道是 shift + enter 直接提交
    atwoodSoInterest
        95
    atwoodSoInterest  
       2020-05-15 16:49:37 +08:00
    破案了,Ctrl enter
    dk7952638
        96
    dk7952638  
       2020-05-15 17:04:00 +08:00
    其实只要不是中文编码,都可以,中文编码的坑太多了
    predator
        97
    predator  
       2020-05-15 17:04:11 +08:00
    如果后端是我……前面传“淘宝|京东|拼多多”或者“1|2|3|4”我都接

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

    至于数据库如何如何,查询如何如何,今后如何如何,这本就不是去和前端争辩的事
    Tdy95
        98
    Tdy95  
       2020-05-15 17:36:59 +08:00
    @Wincer 那么,要如何反驳这个观点呢?

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

    这样能说服吗
    jaylee4869
        99
    jaylee4869  
       2020-05-15 17:51:41 +08:00
    我作为后端现在就是直接传的字符串,前端却问我为啥不传 1234
    tantalu
        100
    tantalu  
       2020-05-15 17:56:36 +08:00   ❤️ 1
    如果字符串参数里面有个不可见字符查问题能查一天。。。
    1  2  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3854 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 09:43 · PVG 17:43 · LAX 02:43 · JFK 05:43
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.