其实老早就像写一点这个话题。几乎我见过的所有大型系统中，都需要一个唯一ID的生成逻辑。别看小小的ID，需求和场景还挺多： 这个ID多数为数字，但有时候是数字字母的组合； 可能随机，也可能要求随时间严格递增； 有时ID的长度和组成并不重要，有时候却要求它严格遵循规则，或者考虑可读性而要求长度越短越好； 某些系统要求ID可以预期，某些系统却要求ID随机性强，无法猜测（例如避免爬虫等等原因）。 独立的生成服务 比如数据库。最常见的一种，也是应用最多的一种，就是利用数据库的自增长序列。比如Oracle中的sequence的nextVal。有多台application的host，但是只有一个数据库。本质上这是耍了个小赖皮，把某分布式系统唯一ID的生成逻辑寄托到一个特定的数据库上，于是分布式系统存在中心节点了。

    这里驳斥一个观点：“尽量都使用class，因为控制样式的时候class的优先级是同级的，id的优先级更高，它的出现会破坏样式优先级的平衡”。首先我觉得这是一个假命题，所谓的“平衡”是不存在的，也没有必要去刻意维护，通过id来表示的内容一定是相对特殊的，优先级自然高一些，这样的优先级设计是如此的自然。我能够接受的全部是class的适用范围仅是一些底层的css基础样式，如oocss里的基础样式，或很多网站都会有common.css文件或general.css文件，里面的东西尽量用class没问题。

    id分配是社区类产品的提交环节中必不可少的一步。任何UGC类内容产生时往往需要分配一个对应的id。 id分配的几种方式  方式一：单点自增分配。全局由一个模块来负责生成id，可保证id从0开始连续递增，数据一般放在本地文件。简洁，但致命的问题是单点故障会导致服务整体不可用。方式一改进：为该模块提供主从复制的能力，或者干脆将数据放在mysql里，利用mysql的主从复制，都一定程度上增强了可用性，减轻了单点故障的影响。方式二：随机/散列分配。通过一些hash算法，比如以时间+随机串为key的md5生成一个唯一的id，关键点在于算法和key的选择要避免冲突。最典型的就是UUID，UUID的标准型式包含32个16进位数字，以连字号分为五段，形式为8-4-4-4-12的32个字符，如550e8400-e29b-41d4-a716-446655440000。