最近 B 站将 AV 号切换到了 BV 号，在知乎引起了较广泛的讨论，本来我只是吃瓜群众，但是在知乎上看到了一个说用 MD5 当地址的回答，我评论 MD5 不可行后，评论区有不少人质疑我，因此写了一个回答来解释为什么 MD5 不可行，以及我对 BV 号的看法。感觉这其实是一个很有意思的问题，所以将我的回答搬到了这里。
以下是我的回答原文：
反对 @V6.47 说的用 MD5 作为地址的回答，我理解 @V6.47 写这个回答多半出于调侃，但是评论区还真有不少人觉得这个方案是可行的。
问题的本质
回到这个问题本身，AV / BV 号本质是个 ID，即「如何设计 AV / BV 号」的本质是「如何设计视频 ID 生成器」，这个问题和「短 URL 系统是怎么设计的？」非常相似。
哈希为何不可行
哈希算法是摘要算法，无限的信息量（视频信息）转换为有限的信息量（定宽字符串），碰撞是必然会发生的。只要有碰撞的可能，那这个方案就是绝对不可行的。
有人补充说我检测一下是不是碰撞了，碰撞给它加 1 / 加 2 / 加3 … 行不行？理论是可行的，但是这样带来了一个成本，每次发号的时候还要去库里查一下这个号发过了没。如果数据量小还好，但 B 站在切 BV 号之前似乎 AV 号就已经发到了 9000W+，每次发号前加锁去 9000W+ 中搜一遍甚至更多遍，发完号再释放锁，这个 ID 发号器的性能绝对是不合格的。况且从存储与搜索的角度来说，一般的存储是基于 B Tree 或类似数据结构的，不能用哈希值作为索引键是基本常识，哈希的随机性会导致写入性能非常差，这也是为什么一般 ID 生成器生成出来的 ID 即使不是严格递增也是趋势递增的。
从安全的角度来讲，MD5 很多年前就已经是不安全的哈希算法了，用 SHA-1 也比 MD5 强，虽然 SHA-1 也已经不安全了，但好歹 SHA-1 目前公开的也只有 Google 在 17 年发布的碰撞案例，而 MD5 的碰撞成本几乎已经没有门槛了。
同样的道理，如果我们要做文件相同性校验，可能是防搬运，也可能是做网盘的秒传功能，用 MD5 在数据量不是大到极端的场景下是没问题的，但发现 MD5 相同时，是一定要再用一些手段去防止 MD5 冲突的：文件元信息比对、换一个哈希算法再算一下等等。
正确的做法
B 站的做法其实就是正确的，B 站这么多年才不到一亿个号，单机发号性能都足够用了，在连续递增的时候使用数据库自增 ID 或者自己实现一套自增 ID 就可以完美的满足需求。如果要求不连续，取消连续递增的逻辑即可，中间可以跳过一部分号不用，或者引入类似 Snowflake 的算法。
更多的可以参考短 URL 的那个问题，基本是相通的。
回到问题本身
单从技术角度，其实 B 站的说辞是站不住脚的：
容纳更多投稿
显然 AV 号作为数字，就算视频数量暴增，也是完全够用的，加一位就可以再获得当前容量的十倍。
保护稿件信息安全
大家的解读不外乎两个点：连续 ID 更容易被爬取，通过 ID 就可以看出来 B 站每天新增的视频数和总视频数。
目前新的 BV 转出来的 AV 已经不是连续的了，即 AV 号的生成已经换了新的方案，那么 BV 号的出现实则解决了不存在的问题：
老的连续的 AV 号是继续保留的，且提供了 AV 到 BV 的转换，那想爬老的依然可以爬；
新的不再是连续的 AV 号生成方案也已经解决了这两个问题，完全没有搞出 BV 号的必要，只需要告诉大家新的 AV 号不再是连续的就 OK 了。
结论
由上可以推断，B 站对 BV 号的解释其实是站不住脚的，BV 号的出现，更多的可能是出于产品层面的考虑。