为什么很多人在需要字符串 ID 的场景下使用 UUID？为什么没有普及 UUID-Slim 这种算法（我编的名字），把 UUID base32 编码一下缩短一半？

[drymonfidelia]

UUID 只能包含 0-F ，信息密度也太低了，只能表示 16^32 个值，如果能把 UUID base32 编码一下，一位能表示 32 个字符，就是 32^16 个值，数量不变，直接缩短一半了。至于为什么是 base32 ，可以自定义编码表保留 UUID 输入不用切大小写、不使用 1 I L O 这 4 个易混淆字符的特性。

UUID 做文件名的例子太多了，随便翻了下电脑，macos 自带的相册 app 文件名就都是 UUID

[cover]

那为什么不用 number 存？

[drymonfidelia]

@cover 对随机 ID 进行加减运算没有意义，如果用自增 ID 会被人看出此类数据数量

[drymonfidelia]

@drymonfidelia #2 会暴露数据数量给用户的意思

[rockyastor]

您是否在搜索 NanoId?
算是短版 UUID 了

[drymonfidelia]

@rockyastor 看了下它用的是 base64 ，这样就失去了 UUID 输入不用切大小写、没有易混淆字符的优点，我觉得 base32 是最合适的

[flmn]

有更多比 uuid 更优秀的 id 方案，时间有序的

[neptuno]

试一下 nanoid

[snowolfy]

捉个虫，16^32 != 32^16 。
16^32 = (2^4)^32 = 2^128
32 ^16 = (2^5)^16 = 2^80
差别还蛮大的

[julyclyde]

硬盘那点钱比起背离行业保准的代价来说，根本不值一提

[drymonfidelia]

@julyclyde 大部分文件系统都有最长路径限制，能减半的话我能多套几层