哈希碰撞概率计算器

直觉以为 N 位哈希要存满 2^N 条才会碰撞，生日悖论说：错。碰撞概率随数量平方增长——50% 碰撞点约在 √(2^N × ln2 × 2) ≈ 1.18 × 2^(N/2)。128 位哈希（MD5）的 50% 点是 2.2×10¹⁹ 条、UUID（实际 122 bit 随机）是 2.7×10¹⁸ 条；64 位哈希的 50% 点只有 51 亿条——这就是为什么短哈希（CRC32、Java hashCode）绝不能当唯一 ID 用：3 万条记录时 32 位哈希碰撞概率已达 11%。

工程应用的决策表：① UUIDv4（122 bit 随机）每秒生成 10 亿个，要 100 年才到 1% 碰撞——放心用；② 短 ID（YouTube 视频号 11 位 Base64 ≈ 66 bit）在千亿规模下需碰撞检测重试；③ 内容寻址（Git 的 SHA-1 160 bit）数学安全但已被构造性攻击（SHAttered），迁移 SHA-256 进行中；④ 分片布隆过滤器的哈希位数直接决定假阳性率。本工具按哈希位数与数据量给出精确碰撞概率，并提供「目标概率所需位数」反算。

生日悖论的直觉校准值得单独做一遍：房间里 23 个人，两人生日相同的概率就超过 50%——直觉按「和我同一天」算是 23÷365 ≈ 6%，但真实场景是「任意两人配对」，23 人产生 253 对组合。哈希碰撞同理：威胁不是「撞上某一个指定值」（那是 2^N 量级），而是「任意两条记录互撞」（2^(N/2) 量级），这就是阈值被开平方的数学根源。

工程决策先回答三个问题：① 数据生命周期内的最大条数 n 是多少；② 是否有对抗场景（攻击者能否构造输入）；③ 碰撞的代价是什么（无感/数据错乱/安全事故）。三个答案直接决定位数与算法选型——分布式 ID 用 UUID 生成器 的 122 bit 随机即可，安全场景必须密码学哈希且加倍留余量。

对抗场景要区分两种碰撞：随机碰撞服从生日悖论概率，攻击者只能靠运气；构造碰撞是算法被攻破后人为制造——MD5 在 2004 年被实用攻破（Flame 病毒用它伪造 Windows 更新证书），SHA-1 在 2017 年被 SHAttered 攻破（约 10^18 次运算）。「数学上还没到生日点」不等于安全，算法本身的健康度优先于位数。

碰撞处理有三种成熟模式：① 检测重试——短链、邀请码系统生成后查库，冲突就重随机，成本低且实测重试率与理论一致；② 校验原值——网盘秒传、缓存系统在哈希命中后再比对内容或二次哈希，防止错认；③ 唯一约束兜底——数据库唯一索引让碰撞变成可捕获的异常而不是静默错乱。用 哈希生成器 可以快速验证两条输入是否真的同值。

位数速查规则（按 50% 碰撞点）：32 位 7.7 万条——只能做校验和；64 位 51 亿条——中小规模分片键、布隆过滤器；122 位（UUIDv4）2.7×10^18 条——分布式 ID 放心用；128 位 2.2×10^19 条——通用去重；256 位 4.0×10^38 条——密码学标准与长期归档。拿不准时，位数加倍的成本远低于一次碰撞事故。