自己封装 uuid 踩的一个小坑
原文中文，约1500字，阅读约需4分钟。
📝
内容提要
在项目中，作者封装了生成全局唯一UUID的函数，但因环境差异导致UUID格式不一致，最终在正式环境中出现错误，影响了后续业务逻辑处理。
🔎
延伸解读
环境差异的重要性
在开发过程中，环境的差异可能导致代码在不同阶段表现不一致。本文中，作者在本地和测试环境中未发现问题，但在正式环境中因使用HTTPS协议导致UUID格式不同，最终影响了业务逻辑。这提醒开发者在测试时应尽量模拟生产环境，以避免潜在的错误。
UUID生成方式的选择
作者尝试了多种UUID生成方式，但未考虑到它们的输出格式可能不同。使用标准化的UUID格式（如8-4-4-4-12）可以避免后续处理中的错误。开发者在封装功能时，应确保输出结果的一致性，以减少因格式不匹配导致的bug。
业务逻辑中的潜在风险
在业务逻辑中，作者使用[name]-[uuid]的方式拼接键值，这种设计在UUID格式不一致时容易出错。开发者在设计数据结构时，应考虑到可能的格式变化，确保分割和解析逻辑的健壮性，以避免在正式环境中出现意外问题。
❓
Q&A
为什么在正式环境中生成的UUID格式与测试环境不同？
正式环境使用HTTPS协议，导致UUID生成时采用了不同的方法，从而格式不一致。
如何生成全局唯一的UUID？
可以使用crypto.randomUUID()方法，或者结合时间戳和自增数生成唯一ID。
封装UUID函数时需要注意什么？
需要确保不同环境下输出结果格式一致，以避免后续业务逻辑处理出错。
在业务逻辑中如何使用UUID？
可以将UUID与其他标识拼接成key，例如使用[name]-[uuid]的格式。
为什么使用UUID时会出现分割错误？
因为在正式环境中生成的UUID包含中横线，而测试环境生成的UUID没有，导致分割时取到的UUID不完整。
如何确保UUID生成的一致性？
应统一使用一种生成UUID的方法，并确保在所有环境中都能生成相同格式的UUID。
🏷️
