之前在用pholcus在做数据收集时候，发现个某大厂的URL，当时有点小意外吧。
https://www.xxxxxxxxxxx/u/ssssssssss?is_hot=1#_loginLayer_xxxxxx 注：ssssssssss为十位数的数字，原数字经过百度查询能查询到该用户，这里避嫌下。
从这个URL出发，前端路由有可能使用vuex router实现的，而且槽点有不少。首先，你会猜测ssssssssss会是什么，看到/u，瞬间就明白了，它是个用户ID，而且极有可能是 AUTO_INCREMENT ID。然后按这个逻辑，把3295362810换成1、1111111111、1111111112再去访问，结果如下：
https://www.xxxxxxxxxxx/u/1 404 https://www.xxxxxxxxxxx/u/1111111111 200 https://www.xxxxxxxxxxx/u/1111111112 200
也不知道，你是否干过这事，数据库ID自增，下标改成1亿开始的。其实，还有一个槽点，我当时加个page查询参数，没想到行得通。而且，这个大厂有个要求非登录用户，不能浏览当前用户的下页，只能浏览首页。现在看来，对程序员来说，形同虚设。
https://www.xxxxxxxxxxx/ssssssssss?is_hot=1&page=2 200
对外提供用户ID查询接口，中间也不加密转换处理，实属不该。
可以参考下Google下一页的做法，对外url会有一层转换，而不是直接使用查询参数page
使用数据库自增ID，有个好处，简单快捷递增，使用innodb聚集索引，性能更好。但是，这里还是建议弃用，它有如下劣势：
- 信息泄露，就像上面的URL一样，很容易让人猜到这个是ID并且自增；
- 数据实体被遍历枚举的风险，如爬虫可以根据自增ID设置遍历规则；
- 与其他实体ID无辨识度；
- 强依赖DB，当DB不可用时导致系统不可用；
- 在异库异构、分表分库的情况下，新旧系统交接或并行运行，数据同步将会是噩梦；
在这里，推荐下美团分布式ID生成系统Leaf（https://github.com/zhuzhong/idleaf），并且有很详尽的学习和使用文档。
,
