23人撞生日概率過半？你的用戶ID正在裸奔

你系統里的用戶ID，可能比你想象的更容易"撞車"。1939年一個反直覺的概率發現，至今仍在讓工程師踩坑。

一圖看懂：生日悖論怎么坑了你的ID設計

原文作者拋了一張關鍵圖——一個在線計算器的界面。輸入三個參數：字符集大小、ID長度、每秒生成量，它直接告訴你這套ID能用多久才會撞。

這張圖的核心就一行字：碰撞概率呈指數增長。1%是條安全紅線，過了就開始危險。

作者舉了個扎心的例子。23個人，兩個同生日的概率就超過50%。聽起來離譜？但數學不會騙人。你的隨機ID也是這個劇本——平方根詛咒。N個可能的ID，大約√N次生成后，碰撞概率就陡升。

這意味著什么？6位數字ID有100萬種組合，但你生成1000個時，撞車概率已經不容忽視。不是"快用完了"才危險，是剛開始用就很危險。

五個硬指標：你的ID及格了嗎

作者梳理了ID設計的五個鐵律，逐條都是血淚：

唯一性——廢話，但有人真翻車。數據庫自增ID在分庫分表場景下，默認配置就是雷。

容量充足——關鍵看生成方式。2位十進制夠給100條記錄編號（00-99），但隨機生成？完全不夠。同樣是2位，計數和隨機的容量天差地別。

不可猜測——看到ID是95，用戶立刻知道前面有1-94。數據量、業務規模全裸奔。敏感場景這是安全事故。

長度可控——只有需要用戶記憶時才重要。內部系統可以忽略，C端產品必須死磕。

生成高效——不能成為系統瓶頸。UUID（通用唯一識別碼）的生成開銷，高并發場景下真能拖垮服務。

五條里最容易被低估的是第三條。透明ID=情報泄露，競爭對手數你的ID增量就能估算日活。

隨機ID的壽命計算器：實操指南

作者甩了一個工具鏈接：https://zelark.github.io/nano-id-cc/

用法很直接：選字符集（大小寫字母？數字？符號？），定長度，填生成速率。輸出兩個數——多久達到1%碰撞概率，多久達到50%。

1%是作者建議的安全線。不是不能更高，是指數曲線太陡，1%之后崩得很快。

舉個例子：用大小寫字母+數字（62個字符），8位長度，每秒生成1000個ID。計算器會告訴你這套配置能用多少年。換成6位？可能幾個月就報警。

這個工具的價值在于把抽象概率變成工程決策。不用懂生日悖論的公式，填三個數就能拍板。

計數vs隨機：兩種路線的容量陷阱

原文對比了兩種生成策略，容量計算完全不同。

計數法（自增ID）：N位十進制 = 10^N個容量。2位就是100個，夠用就夠用，不夠就加位。零碰撞，直到用完。

隨機法：N位、K種字符，理論容量是K^N。但實際可用容量要打骨折——因為平方根效應，√(K^N)次生成后就開始高危。

同樣是"2位數字"，計數法能穩吃100個，隨機法可能生成幾十次就心里發毛。很多工程師栽在這里：看著數字很大，實際很虛。

作者沒明說但暗示了一點：隨機ID必須比計數ID長一截，才能達到同等安全感。短ID+隨機=找死。

什么時候可以"偷懶"

作者給了個豁免條款：MongoDB這類數據庫自增ID，可以暫時不管。但注意是"暫時"——分片擴容時，默認的ObjectId（對象標識符）也可能撞，只是概率極低。

真正需要精打細算的場景：用戶可見的短ID（訂單號、邀請碼）、高并發下的獨立發號器、跨系統全局唯一標識。

這些場景下，ID長度每少一位，都是用戶體驗或存儲成本的實打實收益。但省錯了地方，后期遷移成本十倍奉還。

工程 takeaway：三個 actionable 建議

第一，先算后做。用那個計算器跑一遍，別憑感覺拍長度。1%紅線是作者從實踐中總結的，比教科書更接地氣。

第二，區分內外。內部系統用長UUID隨便造，用戶-facing的短ID單獨設計。別用同一套方案打全場。

第三，留好退路。ID長度設計時預留擴展位，或者準備好換字符集的方案。業務增長超預期時，能平滑升級。

作者最后沒總結，但圖已經說完了——那個計算器界面，就是全文的核心。