为何TinyURL类服务先哈希再Base62编码而非反向？

核心逻辑：先哈希解决原URL的「长度不确定性」，后编码把二进制哈希值转成适合URL的短字符串 #

• 统一输入长度，简化后续处理
  原URL长度可长可短（从几个字符到上百个字符），哈希算法（比如MD5、SHA256）能把任意长度的输入转换成固定长度的二进制数据（MD5是16字节，SHA256是32字节）。这一步把杂乱的长/短URL统一成标准化的固定长度数据，方便后续编码成短字符串。如果反过来先做Base62编码，编码后的字符串长度会和原URL长度正相关（原URL越长，编码后越长），再哈希的话，本质上和直接哈希原URL的结果完全一致——因为Base62编码是可逆的，原URL和编码后的字符串是一一映射的，哈希结果不会有任何变化，这一步编码完全是冗余操作，纯浪费计算资源。

• 贴合短链接的「短」需求
  短链接的核心目标是生成尽可能短的可访问字符串。固定长度的哈希值通过Base62编码后，能得到长度稳定的短串（比如MD5哈希编码后约22位，SHA256编码后约43位）。如果先编码原URL，一个超长URL编码后可能有几十甚至上百位，再哈希得到的结果编码后还是20多位，那前面的编码步骤完全是画蛇添足，直接哈希原URL就能达到同样的效果。

• 哈希的唯一性保障是基础
  哈希的作用是为每个URL生成一个近似唯一的标识（虽然存在碰撞概率，但通过取哈希值的前N位、加盐等方式可以把碰撞概率降到可忽略的程度）。如果先编码后哈希，编码后的字符串只是原URL的另一种格式，哈希它和哈希原URL没有区别，完全起不到额外作用，反而增加了计算步骤。

顺序是否固定？ #

从技术上来说，先编码后哈希不是「不能做」，而是完全没有工程价值，属于多余的步骤。所有实际的短链接服务都选择先哈希后编码，是因为这是最直接、最高效的实现路径，而非技术上的强制要求。

内容的提问来源于stack exchange，提问作者Someone