2

在绝大部分场景下，我推崇方案 1 ，如果有产品端/安全端的特殊需求，我会考虑方案 3 ，只有再极少数场景下，比如日志追踪等，我会考虑 2

4

我（前端）做过的功能，后端给几乎都是用的自增 ID ，极少数场景才会用 2 ，其他目前没遇到

5

6

2 就够用了，还是像楼上说的，只要不是自增就行了。

7

8

方案 4 有一个好处就是，定期更换盐，可以让链接失效，当然让链接失效有好处也有坏处

10

自增 id 除了暴露数据量之外，其他我也没觉得会有啥缺陷，而“暴露数据量”这件事也只有少数场景下才值得被关注，这些场景下就需要具体问题具体分析，比如订单相关场景，其实订单号比 ID 更像事实上的主键（我个人喜欢在绝大多数场景下都保留自增 ID ），业务上基本使用订单号而非主键。

11

肯定不能用自增，首先安全那关就过不去，可以被黑产猜测到数据，遇到爬虫，直接把你整个业务的数据都扒下来。用 md5, uuid, 雪花都行

12

目前项目都用 ULID

13

暴露自增 id 有什么问题吗？
我没见 v2 有什么安全性问题啊

14

数字没问题啊, 只要不是自增就行 足够大 轮训不全的.

16

@felix9ia t 后面的不就是帖子 id 么，你加一减一不也能看到其他帖子么

19

其实 暴露在 url 上和暴露在接口 json 中没啥区别，不自增就行
飞书一样暴露出来的

24

安全性上讲，无所谓自增，有人说方便爬取，想多了。你随机 id 要爬取你也能爬到啊，只要数据是公开的，和自增和随机的没任何区别。
有时候更多的是考虑暴漏业务数据量，以及分布式的时候，才抛弃自增 id 。

25

@dylanqqt 简单来说，别人能猜到你的数据量。比如说订单号自增，竞争对手就能知道你的订单量。比如之前 b 站的 bv 号，最初好像也是自增的，竞争对手就能知道平台的投稿量，后来就换成随机的了（应该不全是这个原因，但是肯定有这方面的考量）

26

主键用的自增 ID, 后端接口查询的时候,sql 语句对 id 加密查询出来,我是这样做的.

28

自增 id 方便调试和 dba 维护，大部分时候自增 id 就够用了，
我只在 serverless 系统上看到用 uuid 的

29

可以暴露，暴露在 url 中与暴露在请求体里有什么区别。
问题是不要使用自增 id 暴露网站后台的规模！
订单 id 自增暴露每日订单数量，商品 id 自增暴露订单数量

31

1

暴露 id 本身没啥问题
暴露 id + 自增 id 可能导致的问题：
1. 对外的系统，纯自增 id 可以推算出数据增长量，暴露业务情况
2. 如果权限做的不好，用户或者爬虫可以通过 id 遍历全部数据
处理方式也很简单：
1. 用一些操作对数据进行加密/编码
2. 完善权限，完善风控

32

2

33

35

@dylanqqt 从 1w 开始，并不能起到很大作用，人家只有作差分就能获取你某段时间内业务规模了
自增 id 也有其他风险，
比如某个接口配置失误，通过订单号直接查询数据，还是比较危险的

36

里面逻辑再拿用户 id,加一层保险

37

根据 RESTful 语义原则，当然是把 ID 放在 URL 里更好，但仅限于 UUID 或其他类似主键。
自增主键的话，建议还是隐藏起来，以免用户可以轻松批量暴库。

38

通常建表时我会创建 id,created_at, updated_at
然后一般情况下我会使用自增 ID;
特殊情况下，我会使用 id+created_at ，只有两个都匹配到才能查询到记录

39

自增 ID 可能会暴露你们业务一天有多少数据，比如订单量之类的。之前我们懒惰 fix 这个问题的方法是随机跳过部分数字来给数据投毒。

40

hackernews is self increased. done.

41

1

42

自增的也无所谓，需要安全的地方，需要其它权限鉴定逻辑。

43

如果你用 innodb 的话，可以把 update 全部改成 insert ignore on duplate update ，你就能得到一个超音速自增的主键（狗头

44

用自增的一些缺点：
1 ，暴露业务数据规模，著名的瑞幸咖啡那件事就是被人蹲点捡小票，通过 ID 推算真实业务量
2 ，方便爬虫写脚本抓数据
3 ，存在缓存击穿问题？？？

45

要看业务是不是数据都公开，京东的商品，论坛的帖子，这种无所谓。资源要做隔离的就需要考虑隐藏了

46

暴露有什么影响吗？
有些 ID 暴露也无所谓啊，就例如这个帖子的 ID 不就在 url 上
涉及到隐私和安全的可以考虑加密或雪花或其他方案加密。
正常用的无所谓的，做好暴露后问题的处理就行。

47

我们有个项目是直接用 ID 异或一个较大的数给前端就行了，然后再异或回来

48

@dylanqqt #30 单单业务规模这一点，确实对小公司可能不算什么，那大公司呢？如果是年营收上百亿，竞争对手虎视眈眈的上市公司呢？对于大公司来说，安全才是第一位的。竞争对手可能已经通过各种渠道收集了你各种各样的信息，再加上这一点交叉验证，底裤都给你扒出来。

50

看完这贴我就把 v 站的第 1,10,100,1000,10000,100000,1000000 贴看了一遍
对很多业务来说这么轻易的能跳转是不可接受的

51

自增 id 然后商户可以 缴纳 30 元 自定义一个“靓号”

52

不连续就行了

53

可以考虑 hashids 对主键进行映射

56

1. 不是自增就行
2. 但如果是大家喜欢的 MySQL 嘛，那就加盐吧

57

自增危险是你的接口处理权限有问题,就和"把某个东西藏起来不想让别人找到"在应用密码学里面提到过是一件不靠谱的事情,做好接口防范才是正道.

58

2 楼正解

59

60

id 暴露很正常，但是还是不要暴露自增的吧

61

62

通过 hashids 装饰自增主键再暴露的方案是否有点自欺欺人？采用这样的方案一般就不会再更改盐值了，盐值对内部开发来说都是可获取的硬编码（），那么总有一天盐值会被暴露到外部

63

@dylanqqt #54 京东这个页面是所有人都可以查看的，并不涉及权限验证，用自增问题不大。如果涉及权限验证，你再用自增，就有可能（比如，权限验证有漏洞）被别人猜到 ID ，然后越权访问。但是，如果用 UUID ，即便权限验证有漏洞，也很难被别人利用。这一点，#32 楼已经说的很清楚了

65

会暴露业务详情的有规律生成的 id 不应该被暴露。比如用户 ID 用了自增的，那可以猜出你有多少用户之类的。

67

如果数据库又想自增，展示又怕暴露可以试试 hashids 的库

68