MD5
128 bit
32 个十六进制字符
老牌算法，速度快。但碰撞已经很容易构造，现在基本只用于校验完整性，不适合安全场景。
常见哈希算法的输出尺寸
单位是比特，括号里是十六进制字符数。日常看到的那串乱码，就是这些字符。
SHA-1
160 bit
40 个十六进制字符
比 MD5 长一点，但同样被攻破。Git 早期用它做对象寻址，现在新项目很少单独依赖它了。
SHA-256
256 bit
64 个十六进制字符
目前的主流选择。比特币、TLS 证书、很多签名方案都在用。长度适中，安全边际也够。
SHA-512
512 位输出，128 个十六进制字符。在 64 位机器上其实跑得挺快，有些场景下比 SHA-256 还顺手。但存储和传输的字节数翻倍，需要掂量。
BLAKE3
输出长度可调，默认 256 位。速度是卖点，并行能力强。如果你的瓶颈在哈希计算本身，可以了解一下。
尺寸和安全，不是简单的正比
哈希越长，暴力碰撞的难度确实越高。但实际系统里，还得看你怎么用。
碰撞概率的直觉
生日问题告诉我们，输出空间为 N 时，大约 √N 次尝试就可能碰撞。128 位对应 2^64 量级，256 位对应 2^128。这个差距不是“两倍”，是指数级的鸿沟。
所以从 MD5 换到 SHA-256，不是长度翻倍那么简单，安全余量提升了好几个数量级。
存储和带宽的账
假设你有一亿条记录，每条存一个 64 字符的哈希，索引体积会明显膨胀。有些团队会在非安全场景下截断哈希，比如只取前 16 个字符做分片键。
截断可以，但要清楚自己在牺牲什么。安全哈希不要随便截。
一个常被忽略的点：哈希大小也影响内存对齐。某些数据库里，32 字节的 SHA-256 刚好和缓存行配合得不错，而 64 字节的 SHA-512 有时会有微妙的性能差异。
存储与传输中的尺寸权衡
哈希大小直接关系到数据库索引、网络协议头和缓存效率。这里列几个常见场景。
内容寻址存储
用哈希当文件名或键。SHA-256 的 64 字符在文件系统里完全没问题，但如果你要拼很长的路径，就得留意系统限制。有些分布式存储会改用 Base32 编码，长度再涨一截。
数字签名与证书
签名本身可能比哈希大得多。哈希尺寸在这里的影响相对小，但证书链里每个签名都带着哈希算法标识，算下来也有点分量。
去重与分片
用哈希做数据去重时，短哈希能省空间，但碰撞会导致错误合并。一个折中做法是存完整哈希用于校验，同时用截断哈希做快速索引。
一个实际的小观察
很多团队在迁移到 SHA-256 时发现，索引膨胀带来的查询变慢其实可以接受，真正麻烦的是历史数据回填和双写期间的逻辑。尺寸本身反而不是最头疼的部分。
几个常被问到的点
哈希越长越安全吗？
在算法本身没有结构性问题的情况下，是的。但 SHA-1 的 160 位比 MD5 的 128 位长，却同样不安全。算法设计比单纯的长度更重要。
能不能把 SHA-256 截一半用？
技术上可以，但截断后碰撞概率上升。如果只是做非安全的校验或分片，问题不大。如果用于签名或密码存储，千万别。
为什么十六进制表示是两倍长？
一个字节 8 位，用两个十六进制字符表示。所以 256 位就是 32 字节，写成 64 个字符。Base64 编码会短一些，但字符集不同。
未来会不会有更长的标准？
SHA-256 目前够用。后量子密码学里有一些更长输出的方案，但还没到全面替换的时候。关注 NIST 的更新就好。
以上内容基于公开资料整理，不构成安全建议。具体场景请咨询相关专家。