哈希计算器 在浏览器本地计算 MD5、SHA-1、SHA-256、SHA-384、SHA-512 与 HMAC，不上传文本或文件。适合做完整性比对、摘要生成和基础验签调试，不等于“加密”。
一种把任意长度数据映射到固定长度输出的函数。好的哈希算法满足三条：
| 算法 | 输出长度 | 速度 | 安全状态 | 典型用途 |
|---|---|---|---|---|
| MD5 | 128 位 (32 hex) | 最快 | 不适合安全用途 | 非对抗性完整性比对、缓存 key |
| SHA-1 | 160 位 (40 hex) | 较快 | 不适合新的安全设计 | 旧系统兼容、历史对象标识 |
| SHA-256 | 256 位 (64 hex) | 中等 | 当前通用默认值 | 下载校验、签名摘要、通用安全哈希 |
| SHA-512 | 512 位 (128 hex) | 中等到较快 | 当前可用 | 更长摘要、部分 64 位环境 |
非安全场景通常还可以，安全场景不要用。MD5 已经不适合证书、数字签名、密码存储这类抗攻击用途；但在下载后做非对抗性完整性比对、生成缓存 key、做去重指纹时仍常见。只要场景里存在“有人故意构造碰撞”的可能，就不要把 MD5 当安全校验。
按用途选。SHA-256 是最通用的默认值；SHA-512 常见于 64 位平台或需要更长摘要的场景；SHA-1 已不适合新的安全校验或签名设计。对大多数工程问题，如果你没有很强的兼容性约束，直接选 SHA-256 通常最稳。
大概率是以下原因之一——换行符：Windows 下下载的文本文件被自动转成 CRLF（\r\n），而官网校验用的是 LF（\n）；BOM：保存 UTF-8 文件时加了 BOM 头（3 字节），hash 当然变；下载不完整：网络中断，实际少了几字节；编码：中文文件保存时 GBK 还是 UTF-8 影响全部字节。校验时用"二进制"模式读取原始字节，别经过任何转换。
理论上不能——hash 是单向函数，从任意长度数据生成固定长度输出，信息有损。但实践中有彩虹表攻击：对常见密码（123456、password 等）预计算 hash 并建表，一查即中。这就是密码存储必须加 salt（每用户独立随机串） + 用慢 hash（bcrypt / argon2）的原因，而不是 MD5/SHA 直接算。
Git 历史上主要把 SHA-1 用作对象标识而不是通用安全签名。今天的 Git 生态也已经在推进 SHA-256 支持，但默认兼容模式仍大量存在。更稳妥的理解是：不要因为 Git 还在用 SHA-1，就把 SHA-1 当作新系统的安全默认值。
不会。hash 是确定性函数——相同输入永远得到相同输出。如果你两次算 MD5 出不同值，一定是输入变了（文件编辑器悄悄改了换行符、系统的时间戳注入、CDN 改了一个字节等）。想验证可以用命令行 md5sum file 或 shasum -a 256 file 跨工具对照。