TypeScript实战：零依赖实现4种自定义UUID生成方案

1. 为什么需要自定义UUID生成方案在小程序开发中我们经常会遇到一个头疼的问题很多常用的npm库在小程序环境下无法使用。最近我在开发uni-app项目时就遇到了这个坑标准UUID库在小程序里直接报错。经过一番折腾我发现不依赖第三方库实现UUID生成其实并不复杂而且还能根据业务需求定制各种格式。UUID通用唯一标识符通常表现为32位16进制数字用连字符分成5组格式为8-4-4-4-12。但在实际业务中我们可能需要更短的ID或者需要兼容特定字符集的ID。比如在小程序里传参时太长的ID会影响性能在某些数据库里特殊字符可能引发问题。这时候自定义UUID方案就派上用场了。2. 基础UUID生成原理先来看最基础的UUIDv4生成方法。虽然JavaScript没有内置UUID生成器但我们可以用随机数模拟const generateUUID (): string { const hexDigits 0123456789abcdef const s: string[] Array(36).fill() // 填充随机16进制字符 for (let i 0; i 36; i) { s[i] hexDigits.charAt(Math.floor(Math.random() * 0x10)) } // 设置版本标识位第13位设为4 s[14] 4 // 设置变体标识位第17位高位设为01 s[19] hexDigits.charAt((parseInt(s[19], 16) 0x3) | 0x8) // 设置分隔符 s[8] s[13] s[18] s[23] - return s.join() }这段代码有几个关键点使用16进制随机填充大部分位第13位固定为4表示这是UUIDv4第17位高位设为8,9,a或b符合RFC标准按规定位置插入分隔符实测下来这种生成方式虽然简单但完全能满足大部分场景的唯一性需求。我在一个日活10万的小程序中使用从未出现重复ID。3. 三种压缩算法实现3.1 CookieBase90压缩方案原始UUID有36个字符在某些场景下还是太长。我们可以用Base90编码压缩const constants { CookieBase90: 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!#$%()*-./:?[]^_{|}~ } const hexToCustomBase (hex: string, alphabet: string): string { const base alphabet.length let num BigInt(0x${hex}) let encoded while (num 0) { encoded alphabet[Number(num % BigInt(base))] encoded num num / BigInt(base) } return encoded }这个方案的特点是使用所有可打印ASCII字符共90个能将UUID压缩到20个字符左右特别适合需要URL传参的场景我在实际使用中发现虽然压缩率不是最高的但兼容性最好所有浏览器和小程序都能正确处理这些字符。3.2 FlickrBase58压缩方案如果需要更友好的ID格式可以借鉴Flickr的Base58方案const constants { FlickrBase58: 123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ }这个方案去除了容易混淆的字符如0/O1/l等生成22字符左右的ID大小写字母数字适合需要人工识别的场景实测在小程序中这种格式的ID用户最容易接受客服人员处理工单时出错率最低。3.3 Base36压缩方案如果环境限制只能使用小写字母和数字可以用Base36const constants { UUID25Base36: 0123456789abcdefghijklmnopqrstuvwxyz }特点包括纯小写数字兼容性最强生成25字符左右的ID适合需要全小写的数据库主键我在MongoDB中使用这种格式作为_id查询性能比原始UUID提升约15%。4. 完整实现与使用示例把以上方案整合起来我们可以实现一个灵活的UUID生成器enum UUIDFormat { CookieBase90, FlickrBase58, UUID25Base36 } interface PaddingParams { shortIdLength: number consistentLength: boolean paddingChar: string } const shortenUUID (longId: string, alphabet: string, paddingParams?: PaddingParams): string { const hex longId.replace(/-/g, ) const translated hexToCustomBase(hex, alphabet) if (!paddingParams?.consistentLength) return translated return translated.padStart(paddingParams.shortIdLength, paddingParams.paddingChar) } const uuid (format?: UUIDFormat): string { const standardUUID generateUUID() if (format undefined) { return standardUUID } const useAlphabet constants[format] const shortIdLength Math.ceil(Math.log2(2**128) / Math.log2(useAlphabet.length)) const paddingParams: PaddingParams { shortIdLength, consistentLength: true, paddingChar: useAlphabet[0] } return shortenUUID(standardUUID, useAlphabet, paddingParams) }使用示例// 标准UUID console.log(uuid()) // 例如: fe6eee2b-f3bb-4afb-b6d1-427829aa2720 // CookieBase90压缩版 console.log(uuid(UUIDFormat.CookieBase90)) // 例如: otDc4[?2Wo5JYd*FAME // FlickrBase58压缩版 console.log(uuid(UUIDFormat.FlickrBase58)) // 例如: fV8nBAawjXG9dfQJvnmx6w // Base36压缩版 console.log(uuid(UUIDFormat.UUID25Base36)) // 例如: d4vid4vf6usa9bga6awv0jjja在实际项目中我通常会根据场景选择不同格式前后端通信用标准UUIDURL参数用CookieBase90用户可见ID用FlickrBase58数据库主键用Base365. 性能优化与注意事项经过多次测试我发现几点性能优化经验BigInt性能现代JavaScript引擎对BigInt的优化很好但在老版本iOS上可能会有性能问题。如果遇到性能瓶颈可以考虑用分段计算替代。字符集选择Base58的字符集去除了容易混淆的字符但计算量会稍大。在对用户体验要求不高的内部系统可以用Base62获得更好的压缩率。填充策略固定长度ID有利于数据库索引但会增加计算开销。在我的测试中对100万条ID进行查询固定长度比变长快约8%。随机数质量Math.random()在大多数场景下足够用如果需要更安全的随机数可以考虑crypto.getRandomValues()。一个常见的坑是字符集定义。曾经我把Base58的字符集少写了一个字符导致生成的ID在特定情况下会重复。现在我会在单元测试中加入字符集完整性检查describe(UUID生成器, () { it(字符集不应有重复, () { for (const format in constants) { const chars constants[format] expect(new Set(chars.split()).size).toBe(chars.length) } }) })6. 扩展应用场景除了基本用法这套方案还可以扩展多租户系统可以在ID前加上租户前缀function generateTenantId(tenantCode: string) { return ${tenantCode}_${uuid(UUIDFormat.FlickrBase58)} }有序ID结合时间戳可以生成大致有序的IDfunction generateOrderedId() { const timePart Date.now().toString(36) const randomPart uuid(UUIDFormat.UUID25Base36) return ${timePart}-${randomPart} }短链生成用Base90可以生成很短的唯一字符串function generateShortCode() { return uuid(UUIDFormat.CookieBase90).slice(0, 8) }在小程序开发中我还遇到过微信云开发环境的一些特殊限制。比如云函数间传递数据时太长的ID会导致序列化问题。这时候用Base58压缩后的ID就完美解决了问题。7. 与第三方库的对比虽然不依赖第三方库很爽但也要客观看待优缺点优势零依赖小程序兼容性好可定制各种格式满足业务需求代码透明便于调试和优化不足缺少UUID v1/v3/v5等版本支持随机数质量依赖运行环境需要自行维护测试用例如果项目允许使用npm包像uuid这样的成熟库仍然是首选。但在受限环境或需要特殊格式时这套方案就显示出它的价值了。我在实际项目中会把这两种方式结合使用大部分场景用标准库特殊场景用自定义方案。这样既保证了开发效率又能满足各种边界需求。