纯前端哈希生成必须用 Web Crypto API：它更安全、无网络请求、原生支持，覆盖所有主流浏览器；CryptoJS 因编码歧义、大小写不一致、兼容性差而不可靠；文件哈希需分块处理防崩溃；MD5 16 位应取 substring(8,24)；换行符差异须文档明确提示。
纯前端哈希生成工具完全可行，且必须用 Web Crypto API——它比第三方库更安全、无网络请求、浏览器原生支持，2026 年已覆盖所有主流浏览器（Chrome 105+、Firefox 100+、Safari 16.4+、Edge 105+）。手写 MD5 或引入 CryptoJS 反而是退步：前者易出错，后者有大小写/填充/编码歧义，且在 Safari 中可能因 TextEncoder 兼容性导致结果不一致。
为什么不用 CryptoJS，而坚持用 Web Crypto API
CryptoJS 默认把字符串按 UTF-8 编码再哈希，但若用户粘贴含 BOM 的文本或手动指定编码（如 GBK），结果就和后端不一致；Web Crypto API 强制要求你显式调用 new TextEncoder().encode()，编码意图清晰。另外，CryptoJS.MD5() 返回的是大写字符串，而多数服务端（如 Python 的 hashlib.md5().hexdigest()）默认小写，容易在联调时卡住。
- 所有现代浏览器中，
crypto.subtle.digest()对"hello"的 MD5 结果恒为"5d41402abc4b2a76b9719d911017c592"（小写、32 位） -
CryptoJS.MD5("hello")在某些版本返回大写，某些返回小写，行为不可控 -
Web Crypto支持SHA-1、SHA-256、SHA-512无需额外加载，算法名直接传字符串"SHA-1"即可
文件哈希计算必须分块，否则大文件直接崩
直接读整个文件进内存调用 digest()，100MB 文件在低端手机上大概率触发 OOM 或页面无响应。正确做法是用 FileReader + stream() 分片读取，每次读 64KB，用 crypto.subtle.importKey() 初始化一个可更新的哈希上下文（实际是反复调用 digest() 并拼接中间状态，但 Web Crypto 不暴露中间态，所以得自己 accumulate ArrayBuffer）。
- 关键点：不能用
file.arrayBuffer()一次性加载，要用file.stream().getReader() - 每 chunk 调用一次
crypto.subtle.digest(algo, chunk)不行——这是重新哈希，不是累加。必须用SubtleCrypto.digest()的 streaming 模式（目前不支持），所以退而求其次：用ArrayBuffer合并所有 chunk，最后整体哈希（适用于 ≤200MB）；或改用Web Worker防止主线程冻结 - 真实项目中，>50MB 的文件建议加进度条，并提示“正在处理，请勿关闭页面”
MD5 16 位其实是 32 位的子串，别硬算
所谓“MD5 16 位”，业内约定俗成是指取 32 位结果的中间 16 个字符（即第 8–23 位，索引 8 到 24），不是重新用不同算法算的。例如 "5d41402abc4b2a76b9719d911017c592" 的 16 位就是 "bc4b2a76b9719d91"。很多工具错误地截取前 16 位，导致和 Java 的 MessageDigest 或 Python 的 md5.hexdigest()[8:24] 对不上。
立即学习“前端免费学习笔记（深入）”；
- 务必用
hashHex.substring(8, 24)，不是hashHex.slice(0, 16) - 大小写切换只需
hashHex.toLowerCase()或.toUpperCase()，别用正则替换，慢且易错 - 复制按钮必须用
navigator.clipboard.writeText()，旧版document.execCommand("copy")已被 Chrome 95+ 废弃
最易被忽略的一点：文本输入时，textarea 的换行符在 Windows 是 \r\n，macOS/Linux 是 \n，如果后端校验用的是 Linux 环境，而你本地测试用 Windows 输入，哈希值天然就不等。解决方法不是统一换行符，而是明确文档里写“请确保换行符一致”，并在 UI 上加个小提示 icon，hover 显示“当前使用系统默认换行符”。
