关于「GUID」，我把要点压缩成几个关键步骤。看完不用背公式，遇到问题知道往哪儿查、怎么验算就够了。
这几个问题问得最多
UUID是128位全局唯一标识符，常用版本：v1(时间+MAC地址)、v4(随机)、v5(命名空间+名字哈希)。v4最常用，碰撞概率极低(2^122种组合)。格式8-4-4-4-12十六进制如550e8400-e29b-41d4-a716-446655440000。多写多测自然熟练，开发就是踩坑填坑的循环。能成熟库就别自己造轮子，特别是加密、解析、并发这种容易出错的领域。
再往深走一步
NanoID比UUID短(21字符)、URL友好、速度更快。雪花算法(Snowflake)生成有序长整型ID(时间戳+机器ID+序列号)，适合数据库主键(有序索引效率高)。UUID无序不适合做MySQL主键(索引碎片)。错误信息要看完整，别只看第一行，真正的根因往往在堆栈深处。编码统一UTF-8能避免大部分乱码问题，全链路都要统一。
顺便提几个注意点
先理解概念。GUID属于开发基础知识，搞懂底层原理(编码规则、算法逻辑、协议规范)比记API更重要。原理通了，换语言换框架都能快速上手。光看不动手永远学不透，写个小demo跑一遍胜过读十篇文章。版本控制和单元测试是基本功，别图省事跳过。
几个要注意的地方
把这几点贴在屏幕上盯着，算的时候随时对：
- v4随机版本2^122种组合，碰撞概率低到可忽略
- UUID无序做MySQL主键会导致B+树页分裂，影响性能
- 雪花算法生成有序长整型(时间戳+机器ID+序列号)适合主键
- NanoID比UUID短(21字符)、URL友好、生成快
这一篇信息量不小，建议收藏起来，用到的时候翻出来对着算。比临时百度靠谱多了。
安全三件套：防SQL注入、防XSS、防CSRF，缺一不可。多写多测自然熟练，开发就是踩坑填坑的循环。生产环境要考虑异常、并发、性能，不能只测正常流程。错误信息要看完整，别只看第一行，真正的根因往往在堆栈深处。版本控制和单元测试是基本功，别图省事跳过。写完代码用边界案例测一遍，比读十遍代码都管用。日志要记关键节点和异常，出问题排查全靠它。光看不动手永远学不透，写个小demo跑一遍胜过读十篇文章。原理比API重要，原理通了换语言换框架都能快速上手。
常见问题
【UUID和NanoID哪个好？】NanoID更短(21字符vs UUID36字符)、URL友好、生成快。UUID更通用(标准广泛支持)。URL场景NanoID好，需要标准兼容选UUID。
【UUID是什么？会重复吗？】128位全局唯一标识符，v4随机版本2^122种组合，碰撞概率低到可忽略。格式8-4-4-4-12十六进制。用于分布式系统唯一标识，不依赖中心分配。
【GUID是什么？】属于开发基础知识范畴，是程序员日常会用到的概念或工具。理解原理(编码/算法/协议)比记API重要，原理通了换语言框架都能快速上手。
【UUID适合做数据库主键吗？】不一定。UUID无序，做MySQL主键会导致B+树索引频繁分裂(页分裂)影响性能。有序ID(自增或雪花算法)更适合主键。UUID适合做业务唯一标识，主键用有序ID。
