一般对称加密算法对大数据块的加密性能比较好，但这种微型级别的数据的加密时间却也是毫秒级的，存取计算个用户名都要占用毫秒时间，太占用 cpu 了，不如不加密，也不如随机 id 。

随机 id 是可以考虑的，不过主流数据库随机 id 的存取性能显然也达不到秒内百万次。

@chevalier 其实可以数据库主键递增，取出的时候计算出密文 id ，发送给前端的数据显示的是密文 id ，同时后端可以通过前端传回的密文 id 找到其他用户的真实主键 id ，全程全数字，压力比一些字符串 id 方案要小。

@x1aoYao 不太容易，我用的映射表是 1000 对 1000 的，随机生成，由密钥做成的随机种子（各个过程中都有盐），但我发现主要问题还是+1 的情况下改变位数太少，这些个基本操作还得再重复很多次可能才能消除掉肉眼规律。

@tool2d 不排除其用多个 ip 或者找到某个漏洞，在短时间内多次尝试，所以我主楼给出连续 100 个算是比较多了，其实正常来说应该拿不到这么多 id ，但就是这 100 个数据也被发现出规律，尽管要进一步确认规律也不是那么容易的。

@tool2d 首先有效数字就一共只有 13 位，如果能无限拿到具体对应的 id ，爆猜都能出结果，密钥没这么重要。

@x1aoYao 简单来说，如果每个 id 只是末尾加一的话，除了映射，其他移位、异或、置换改变的数字及其顺序都是极为有限的，本来就很容易找出规律，成熟的加密算法分解来说也是这些个基本操作，但轮次会多很多，而且选取的固定参数可能有其特殊性（自创加密算法可能很难找到合适参数）。

@x1aoYao 首位是用来对齐的，实际只有 12 位，其实我的思路跟你的差不多，不过不知道要做到几个轮次才能看起来毫无规律。

@tool2d 是有密钥的啊，中间一些具体的参数是由密钥生成的，当然主要是算法太简单，有密钥应该也百分百会被破解。

算法公开的前提是复杂度的证明原则上可以超过宇宙时间，我这个算法显然不能，成熟的算法各种操作都十几轮几十轮，我这个只有个位数轮次，如果能无限拿到明文 id ，破起来轻轻松松。

市面上完整的加密算法不是不好，就是加密出来的串太长，同样不具有可读性，同样也没见过多少人真的拿用户 id 上 AES 的，甚至连 hashid 都少见，八股文里也就提提雪花、uuid ，偶尔见到有人来点大数异或、加减乘除，甚至纯纯递增也不少见，比如 B 站就用了很多年的递增 AV 号。

@Bay0net 因为密文 id 也可以存成 64 位整数，性能比字符串好，所以应该会用密文 id 来作为索引获取一部分数据，起码不会在前端暴露原始 id 。

@Bay0net 对对对，原来是这样破的，虽然代码里面没有 25 ，但是 25 倍数确实会有规律，然后再做差指确实可以找出别的规律，如果随机递增 id 能进一步避免吗？

@Tidusy 对照过 AES 和 DES ，取了里面的一些步骤进行简化写的，整个代码加密解密一起不过百行，性能当然比这两个号，同时安全性也不如这两个，但好在理论上加密过程可以不公开。一共不到百行的代码和密钥也差不多了，动态语言可以直接执行，静态语言就打包成二进制调用。

@MozzieW 中间过程没有不可逆的过程，跑了一亿个数字 id ，也生成了一亿个密文 id ，没有重复的。循环规律没法证明不会出现，但在没有大样本对应的情况下，可能发现不了。

@idealhs 所以不知道算法，理论上应该是非常难破解的对吧，所以说现代加密算法安全性的前提都是算法公开吗，我这个算法其实可以看成超简化的 DES 。

@gps949 确实没考虑过随机 id ，以前学到的都要求尽可能顺序 id ，甚至+1id ，想想随机 id 也不是不行

hashids 我试了下，和主楼同样的数字 id ，生成的数组串是：

["NwZsPYi3Xidjik8iKLiDRirV", "meRs9ri4niKqi69i0eil6iKW", "8oVsZqioni9Xiv4i6zinjizo", "P7LszLiEPiWZiapimridRiJp", "RWJsdziqXi2wieYiVZirAiRK", "4Mps0ridwiEli08iO6iWziVZ", "rObsMkivdiabik6iKlidNivG", "XGysN0iKziADiBqiLviwAirY", "zwpsMjiPviBViVGiDWiXEiZ9", "NwZsPYi3Xidjik8iKLiDasry", "meRs9ri4niKqi69i0eilXsK6", "8oVsZqioni9Xiv4i6zinZsza", "P7LszLiEPiWZiapimridDsJb", "RWJsdziqXi2wieYiVZirKsR4", "4Mps0ridwiEli08iO6iWDsV4", "rObsMkivdiabik6iKlid8svV", "XGysN0iKziADiBqiLviw0sr3", "zwpsMjiPviBViVGiDWiXjsZq", "kKysdoin4irqi7Miynib9s84", "meRs9ri4niKqi69i0eil2cKw", "8oVsZqioni9Xiv4i6zinVcz9", "P7LszLiEPiWZiapimridacJO", "RWJsdziqXi2wieYiVZirzcRJ", "4Mps0ridwiEli08iO6iWZcVD", "rObsMkivdiabik6iKlidrcvm", "XGysN0iKziADiBqiLviw8crV", "zwpsMjiPviBViVGiDWiXycZv", "kKysdoin4irqi7MiynibYc8r", "n7ysZPik4iX7iVGiaBi9AcXZ", "8oVsZqioni9Xiv4i6zinrUz0", "P7LszLiEPiWZiapimridOUJx", "RWJsdziqXi2wieYiVZirPUR3", "4Mps0ridwiEli08iO6iW3UVo", "rObsMkivdiabik6iKlidkUvp", "XGysN0iKziADiBqiLviwJUry", "zwpsMjiPviBViVGiDWiXWUZa", "kKysdoin4irqi7Miynib8U8O", "n7ysZPik4iX7iVGiaBi9EUX7", "6y7sNdi37iA9iEoiXliMxUWD", "P7LszLiEPiWZiapimridLCJE", "RWJsdziqXi2wieYiVZirkCRd", "4Mps0ridwiEli08iO6iW7CVj", "rObsMkivdiabik6iKlidoCvx", "XGysN0iKziADiBqiLviw2CrR", "zwpsMjiPviBViVGiDWiXOCZJ", "kKysdoin4irqi7Miynib7C8w", "n7ysZPik4iX7iVGiaBi9qCXm", "6y7sNdi37iA9iEoiXliM4CWz", "EKvsPBiXaieGidPikdi9kC3a", "RWJsdziqXi2wieYiVZirNIR7", "4Mps0ridwiEli08iO6iWGIVB", "rObsMkivdiabik6iKlidxIvN", "XGysN0iKziADiBqiLviwNIrj", "zwpsMjiPviBViVGiDWiXeIZx", "kKysdoin4irqi7Miynib0I8J", "n7ysZPik4iX7iVGiaBi9vIXK", "6y7sNdi37iA9iEoiXliM2IWB", "EKvsPBiXaieGidPikdi94I3A", "DbLsMBi8yiNXiwmixGiwyI96", "4Mps0ridwiEli08iO6iWauVO", "rObsMkivdiabik6iKlid9uv4", "XGysN0iKziADiBqiLviwKurZ", "zwpsMjiPviBViVGiDWiX0uZr", "kKysdoin4irqi7MiynibVu80", "n7ysZPik4iX7iVGiaBi9GuXk", "6y7sNdi37iA9iEoiXliMyuW4", "EKvsPBiXaieGidPikdi9Au38", "DbLsMBi8yiNXiwmixGiwxu9V", "eMwsOniBriAxiKAieoioOuRq", "rObsMkivdiabik6iKlid0TvK", "XGysN0iKziADiBqiLviwZTra", "zwpsMjiPviBViVGiDWiXpTZ7", "kKysdoin4irqi7MiynibwT8a", "n7ysZPik4iX7iVGiaBi9YTXb", "6y7sNdi37iA9iEoiXliMoTWm", "EKvsPBiXaieGidPikdi9aT3x", "DbLsMBi8yiNXiwmixGiw3T9l", "eMwsOniBriAxiKAieoio0TRW", "xqos7vio0iKeiv4iB6iXeTYM", "XGysN0iKziADiBqiLviwpSrB", "zwpsMjiPviBViVGiDWiXZSZE", "kKysdoin4irqi7MiynibJS8A", "n7ysZPik4iX7iVGiaBi9ZSXM", "6y7sNdi37iA9iEoiXliMXSWr", "EKvsPBiXaieGidPikdi9JS3y", "DbLsMBi8yiNXiwmixGiwBS94", "eMwsOniBriAxiKAieoioRSRj", "xqos7vio0iKeiv4iB6iXPSYL", "0VbsNYimdi6Zi4VijRi3kSv2", "zwpsMjiPviBViVGiDWiXoHZk", "kKysdoin4irqi7MiynibKH8y", "n7ysZPik4iX7iVGiaBi9kHXB", "6y7sNdi37iA9iEoiXliMrHWV", "EKvsPBiXaieGidPikdi9VH3M", "DbLsMBi8yiNXiwmixGiwbH97", "eMwsOniBriAxiKAieoiojHRb", "xqos7vio0iKeiv4iB6iX0HY8", "0VbsNYimdi6Zi4VijRi3ASvD", "AK7syxiEXiA8imqi2Mi4OHDV", "NwZsPYi3Xidjik8iKzsDRiry"]

太长了，而且性能只有我这个自制算法的十分之一这样。。
当然，安全性肯定好过我这个，至于加密过程过于简单，当然是尽可能不公开代码。

@swulling 用户 id 这种东西，说有价值也算有价值，但暴露了问题也不大。就像 B 站的 BV 号，也算有价值，过很快也被破解了。也不知道大佬是怎么破解的，就算知道部分视频对应的 AV 号，竟然连具体算法都可以写出来，除了内部泄露真的能做到吗。