企业官网建设流程全解析

做前端这几年，遇到"文件传上去到底对不对""两个安装包是不是同一个""接口签名拿什么算"这类问题，我基本上都是打开命令行敲一条sha256sum。后来次数多了，索性自己写了一个浏览器里直接跑的SHA-256哈希生成器——文本拖进去、文件拖进去，几毫秒就输出64位十六进制摘要。这个需求和实现过程让我把SHA-256算法从头到尾研究了个透，今天就把这套东西掰开聊：这个哈希到底在算什么、前端实现有几条靠谱路径、核心代码怎么写，以及我踩过的几个真实坑，全部分享出来。

不管你是刚入行的前端新手，还是写了好多年业务代码的老开发，只要你需要处理文件完整性校验、内容去重、缓存key生成，或者单纯想搞懂"哈希原理"这个词背后的真实运算过程，这篇文章都值得你花十分钟看完。

1. SHA-256是什么：先搞懂哈希函数的三件事

1.1 哈希不是加密：单向函数的核心区别

很多人一上来就把哈希和加密混为一谈，这是第一个认知误区。加密是可逆的——你有密钥或者知道算法，就能把密文还原成原文；哈希完全相反，它是单向的，你只能从原始数据算出摘要，却没法从摘要反推出原始数据。用个生活化的类比：哈希就像榨汁机，橙子进去，橙汁出来，但你把橙汁放在那里，永远变不回一个完整的橙子。

SHA-256的全称是Secure Hash Algorithm 256-bit，属于SHA-2家族，由美国国家标准与技术研究院发布。它接收任意长度的输入，输出固定256位（也就是32字节、64个十六进制字符）的摘要。这个"任意长度进，固定长度出"的设计，决定了它非常适合用来做数据指纹：不管是一行文字、一个PDF，还是一整个安装包，算出来的指纹长度都一样。

1.2 三个关键特性：确定性、单向性、雪崩效应

哈希函数之所以能在工程里被广泛使用，靠的是三个核心特性，我建议你把这些刻在脑子里。

第一是确定性。同一个输入，不管你在哪台机器、用什么语言、什么时候调用，算出来的SHA-256永远是同一个值。这是"校验"能成立的前提。

第二是单向性。从摘要几乎不可能反推出原文。不是说数学上完全不可能，而是计算复杂度高到不现实。唯一可行的反推方式是暴力猜——把可能的值一个个算过去比对，这就是为什么哈希撞库攻击需要配合字典或彩虹表。

第三是雪崩效应。输入哪怕只翻转一个比特，输出的256位摘要里大约会有一半的位跟着变化。所以你经常会看到别人说"改一个字符，整个哈希面目全非"，这不是BUG，这正是哈希函数的核心设计目标。它保证了无法通过局部相似性去推测原始数据的相似性。

另外还有一个工程上非常重要的特性：抗碰撞性。很难找到两个不同的输入，却得到同一个SHA-256输出。理论上哈希碰撞一定存在（因为输入空间无限，输出空间有限），但SHA-256的碰撞难度高到在现实计算条件下几乎不可能出现，这也是它能替代MD5和SHA-1成为主流校验算法的原因。

1.3 前端为什么需要SHA-256生成器

后端做哈希校验很常见，那前端算哈希有什么用？我自己的实际经验里至少有四个场景是高频的。

第一个就是文件完整性校验。比如用户上传安装包，前端先算好SHA-256，提交给后端比对——如果后端拿到的文件哈希对不上，说明文件在传输过程中损坏了或者被篡改过，可以尽早拦截。前端直接算的好处是省去了一次文件上传和回传的往返，用户体验也更流畅。

第二个是内容去重和文件去重。相同内容的文件，哈希一定相同。我在某个项目中做过一个图片管理工具，就是靠前端算SHA-256来判断用户拖进来的图片是否已经存在，从而避免重复存储。

第三个是缓存和版本控制。前端拿数据时可以用内容哈希做缓存key，内容变了哈希就变，缓存自动失效，比时间戳策略精准得多。Git的commit之所以能做到内容寻址，本质上也是这个思路。

第四个是接口签名参数。在前后端分离的场景里，某些敏感接口要求客户端生成签名，前端对请求体做哈希或参与哈希运算，能有效防止参数在传输中被篡改。

顺带提醒一句：SHA-256不适合直接用来存用户密码。哈希虽然不可逆，但普通哈希速度太快，攻击者可以用GPU每秒跑几十亿次暴力猜测，配合常见密码字典，弱密码很快就沦陷。存密码应该用PBKDF2、bcrypt这类专门设计的慢哈希算法，给哈希加上盐再反复迭代。这个知识点和前端哈希生成器放在一起容易被忽略，但你迟早会碰到。

2. SHA-256算法原理拆解：填充、调度、压缩到底在算些什么

2.1 整体流程预览：四个步骤走完一遍

很多人学SHA-256被劝退，是因为网上资料一上来就甩公式。其实它的整体流程并不复杂，一句话就能概括：把输入消息填充到固定块大小，然后每一块都通过一个压缩函数去更新内部状态，最后把状态输出成摘要。

具体来说分四步：

1. 消息填充（Padding），把任意长度的消息补成512位的整数倍。
2. 分块解析，把填充后的数据按512位切成若干个块。
3. 每块进入压缩函数，迭代64轮，不断更新8个32位寄存器（总共256位）。
4. 所有块处理完后，把8个寄存器按大端序拼接，输出64位十六进制字符串。

你可以把消息块想象成流水线上的标准包装箱，每个箱子固定512位宽。压缩函数就是箱子的处理机，每过一箱，它就把机器内部的8个状态值搅动一次。最后一箱处理完，机器状态就是你要的哈希值。

2.2 第1步：消息填充（Padding）——为什么一定要补位到最后448位

填充规则看起来很古怪，但理解之后就会觉得设计得很巧妙。规则分三小步：

• 原始消息末尾先补一个"1"比特。在字节层面来看，就是在数据末尾追加一个0x80字节（二进制是10000000）。
• 然后一直补"0"，直到当前长度除以512的余数等于448位（也就是56字节）。
• 最后再追加8字节（64位），用来存放原始消息的比特长度。

也就是说，不管你的原始消息多长，填充后的总长度一定是N*512 + 64位，最后64位专门存原始比特数，前面448位是消息加填充。为什么是448？因为要留出最后8字节给长度信息，512减去64正好是448。

我举个具体例子。假设原始消息是字符串"abc"，长度是24比特。填充过程是这样：先补0x80，再补零到第448位，最后放入64位的原始长度24（二进制：00...011000）。最终这一整块恰好512位。如果消息刚好是448位，仍然要填充出一个完整块；如果消息长度已经等于512的倍数减64，那填充后也会多出一个新块来存放长度。这个"多一个块"的边界情况，是新手自己在写代码时常漏掉的地方。

填充为什么要带上原始长度？因为哈希算法必须保证长度不同的消息最后产生不同的摘要。如果没有长度信息，"a"和"a"后面跟一百个零填充后可能长一样，哈希就乱套了。

还有一个容易忽略的细节：长度字段用大端序存放。S HA-256内部几乎所有多字节数据都用大端序处理，如果你按小端解析，整个计算结果就不对。

2.3 第2步：消息调度（Message Schedule）——从16个字扩展到64个字

填充完成后，每个512位的块会先被切成16个32位的字（word），记作W[0]到W[15]。但压缩函数需要64个字。剩下48个字怎么来？靠消息调度公式算出来。

这个公式是：

W[t] = σ1(W[t-2]) + W[t-7] + σ0(W[t-15]) + W[t-16]

其中加法是模2的32次方（也就是整数溢出后自动截断）。σ0和σ1是两个固定函数，它们做的事情是：把输入字循环右移若干位，再和另一个移位数做异或，再加上右移7位的结果。它们的表达式是：

σ0(x) = (x >>> 7) ^ (x >>> 18) ^ (x >> 3) σ1(x) = (x >>> 17) ^ (x >>> 19) ^ (x >> 10)

注意这里>>>表示逻辑右移，>>是算术右移，两者在JavaScript里尤其容易搞混——这个我在后面避坑章节还会提到。

你可以把消息调度理解为"把原本16个输入字的信息，经过移位和异或，扩散到了后续48个字里"。这样即使原始消息只有一个比特不同，经过一轮调度后，64个字里会有很多位置发生变化，雪崩效应就是从这里开始放大的。

2.4 第3步：压缩函数——64轮循环里到底发生了什么

这是SHA-256的心脏。压缩函数维持8个32位寄存器，官方命名为A、B、C、D、E、F、G、H。算法开始前，它们被初始化为8个特定常量（后面会讲这些常量怎么来的）。

每一轮的流程，目前网上最常见的描述是这段伪代码：

T1 = H + Σ1(E) + Ch(E, F, G) + K[t] + W[t] T2 = Σ0(A) + Maj(A, B, C) H = G G = F F = E E = D + T1 D = C C = B B = A A = T1 + T2

其中Ch是选择函数，按E的位来决定F和G哪个被选出来，表达式是(E & F) ^ (~E & G)，相当于一个二选一多路选择器。Maj是多数函数，对A、B、C的同一比特位置做"少数服从多数"，表达式是(A & B) ^ (A & C) ^ (B & C)。Σ0和Σ1是另外两个循环移位异或的组合：

Σ0(A) = (A>>>2) ^ (A>>>13) ^ (A>>>22) Σ1(E) = (E>>>6) ^ (E>>>11) ^ (E>>>25)

看到这个是不是觉得跟前一节的σ0/σ1很像？是的，它们都包括移位和异或，只是移位量不同。这样设计的目的说白了就是：把寄存器内部不同位置的比特互相混合，让任意一位的改变能迅速影响后续很多位。

64轮跑完之后，这一块的压缩结果还要和上一轮的寄存器状态相加（同样是模2的32次方）。也就是说每个块的结果会累积到全局状态里，而不是被这一块独立重置。这也是为什么处理多个块时一定得顺序进行——这一块的输出依赖前面所有块的状态，没法并行。

2.5 那些"魔法常数"从哪来

你可能注意到压缩函数里有个K[t]，每轮一个，一共64个；8个初始寄存器A~H也各有固定值。曾经有读者问我，这些数是拍脑袋定的吗？其实不是，它们来自数学常数。

• 前8个质数（2、3、5、7、11、13、17、19）的平方根的小数部分，取前32位，构成了A~H的初始值。
• 前64个质数（2到311）的立方根的小数部分，取前32位，构成了K[0]到K[63]。

因为无理数的小数部分在二进制下没有任何规律，相当于一组分布均匀的随机比特，可以让输出的统计特性更好，也让哈希值看不出任何输入模式。这属于密码学哈希算法的标准设计做法——用"看起来随机但可复现"的常数来打乱数据。

到这里，算法原理的大框架已经有了：填充、切块、调度、压缩。你不需要一次性记住所有公式细节，但应该能向同事解释清楚"SHA-256为什么不可逆、为什么雪崩、为什么是256位"。有了这个基础，下一步才能看懂前端代码里每一步在干什么。

3. 前端实现方案选型：三条路怎么选

3.1 首选Web Crypto API：一行调用，性能和安全性都拉满

现代浏览器内置了一套原生加密接口，叫Web Crypto API。用它对数据进行SHA-256，核心只需要一行：

const digest = await crypto.subtle.digest('SHA-256', data);

crypto.subtle.digest接收两个参数：算法名和待计算的数据。数据必须是ArrayBuffer或TypedArray，不能直接传字符串。返回的也是一个Promise<ArrayBuffer>，里面装的是32字节的原始摘要。浏览器底层用的是系统级加密实现（比如macOS/iOS的Common Crypto、Windows的CNG），性能远超任何JavaScript层面的实现。

这里我提醒一个容易踩的坑：crypto.subtle只在安全上下文（Secure Context）里可用。什么叫安全上下文？HTTPS页面，或者localhost。如果你在局域网IP的HTTP页面上调试，crypto.subtle会直接是undefined，一行代码都跑不起来。这个问题我后面专门有个章节细说。

3.2 手写实现原理版：学习价值拉满，但别上生产

如果你和我一样有强迫症，想知道每个字节是怎么被搅动的，可以手写一个纯JavaScript实现的SHA-256。这个过程极其锻炼人对位运算、整数溢出、大端序的理解，而且写完之后再看文档公式会特别有底。

但手写版本不建议上生产环境。原因有三：第一，性能比不过浏览器的原生实现；第二，自己实现的正确性容易出错，特别是循环移位、加法溢出、填充边界这些细节；第三，Web Crypto API经过各大浏览器厂商和密码学社区长期审计，而你的手写代码没有。做学习工具可以，做线上校验工具还是用原生接口稳妥。

3.3 第三方库：什么时候才真的需要

你可能会问："那还有必要装第三方库吗？"我的判断是：当你需要流式处理大文件时，才有必要。

crypto.subtle.digest有个天然限制：它不支持增量计算。你必须把完整的数据一次性传入，才能算出整体哈希。文件小还好，文件一旦上几百MB甚至几个GB，你不可能把整个文件读进内存等着算。

这时候可以用hash-wasm这类支持增量哈希的库，它让你可以先init，然后一段一段update，最后digest。而且它是用WebAssembly实现的，性能接近原生，同时能在Web Worker里跑，不会卡住主线程。我在后面大文件部分会给出具体代码演示。

3.4 三条路线对比总表

在我实际做工具时，最终采用的是Web Crypto API做主逻辑，同时留了一个hash-wasm的降级路径给超大文件。两边切换的成本其实很低，因为接口设计很相似。建议你在项目里也做成"核心逻辑可替换"的结构，不要写死某个实现。

4. 手把手实现一个前瑞SHA-256生成器：核心代码与完整页面

4.1 基础版：文本输入即时出哈希

先从最简单的文本场景开始。页面放一个输入框，用户输入内容，我们实时把SHA-256算出来。核心函数长这样：

async function sha256Hex(input) { const encoder = new TextEncoder(); const data = encoder.encode(input); const digest = await crypto.subtle.digest('SHA-256', data); return [...new Uint8Array(digest)] .map((b) => b.toString(16).padStart(2, '0')) .join(''); }

这一段代码有几个点值得展开讲。

TextEncoder把字符串编码为UTF-8字节流。如果你直接用charCodeAt去拿字符编码，很容易踩进中文乱码的坑。crypto.subtle.digest返回的是ArrayBuffer，不能直接打印，必须转为Uint8Array。Uint8Array里每个元素是0到255的数字，用toString(16)转成十六进制字符串。但小于16的数字转出来只有一位，比如十进制10转成a，而标准SHA-256要求每字节必须两位十六进制，所以必须padStart(2, '0')补零，否则哈希不只是少了长度，结果都对不上。这个坑我实际遇到过，后面统一讲。

在React/Vue等框架里用这个函数也简单，无非是在input事件里调用并写入状态。但有一点注意：digest是异步的，如果用户输入很快，你可能会并发触发多次计算，返回值顺序可能和输入顺序不一致。简单的处理方式是用中间变量记录上次输入，或者直接加个防抖。这种小细节不处理，测试阶段没事，用户快速粘贴大段文本时就会看到哈希一顿乱跳。

4.2 进阶版：文件拖拽与哈希计算

文本搞定后，再处理文件。文件场景的核心区别是：输入数据变成了二进制字节，不需要也不能走TextEncoder。直接把文件内容读成ArrayBuffer，交出去算就行。

async function hashFile(file) { const buffer = await file.arrayBuffer(); const digest = await crypto.subtle.digest('SHA-256', buffer); return [...new Uint8Array(digest)] .map((b) => b.toString(16).padStart(2, '0')) .join(''); }

file.arrayBuffer()是现在兼容性比较好的直接方法。如果你要兼容更老的浏览器，可以用FileReader的readAsArrayBuffer，回调里拿到result。两者的数据路径完全一样，只是一个走Promise一个走回调。

写拖拽交互的时候，有件小事值得提：drop事件里拿到的e.dataTransfer.files是一个FileList对象，它长得像数组但不是数组，for...of可以遍历，但如果你想用Array的方法，需要先Array.from转一下。同时别忘了对拖拽区域做dragover事件的preventDefault，否则浏览器会直接打开那个文件而不是触发你的拖拽逻辑。

我给一个最小可用的示例片段：

dropZone.addEventListener('dragover', (e) => { e.preventDefault(); dropZone.classList.add('dragging'); }); dropZone.addEventListener('dragleave', () => { dropZone.classList.remove('dragging'); }); dropZone.addEventListener('drop', async (e) => { e.preventDefault(); dropZone.classList.remove('dragging'); const files = Array.from(e.dataTransfer.files); for (const file of files) { const hash = await hashFile(file); appendResult(file.name, file.size, hash); } });

多个文件就遍历每个计算。配合一个进度提示（哪怕只是一个"计算中..."的文本），用户体验就基本合格了。

4.3 大文件处理：分段读取不要一次塞进内存

如果你的工具要处理几百MB甚至几个GB的文件，上面那种一次读进内存的方式会崩——浏览器会卡死甚至崩溃。这时候正确的姿势是分段读取加上增量哈希。

我用hash-wasm举例，因为它的增量接口最直观：

import { createSHA256 } from 'hash-wasm'; async function hashLargeFile(file, chunkSize = 4 * 1024 * 1024) { const hasher = await createSHA256(); hasher.init(); let offset = 0; while (offset < file.size) { const chunk = file.slice(offset, offset + chunkSize); const buffer = await chunk.arrayBuffer(); hasher.update(new Uint8Array(buffer)); offset += chunkSize; } return hasher.digest(); }

建议把这段代码放在Web Worker里执行，让主线程只负责显示进度和渲染结果。大文件读取本身是异步IO，浏览器不会完全阻塞，但哈希运算本身还是有CPU消耗的，在主线程跑会让页面卡顿。Worker的方式很成熟：主线程把文件对象通过postMessage传给Worker，Worker按块读、按块算，做完再把结果传回。

关于chunkSize的选择，我实测下来4MB到16MB是比较舒服的区间：太小会导致循环次数多且IO开销大，太大会出现一次读取分配大内存的抖动。可以按目标用户机器的内存情况做个阈值判断，比如文件小于128MB就直接整读，大于500MB再走Worker增量路线。

4.4 组装一个完整的工具页面

一个小工具的核心代码写完后，剩下的就是把它包成一个干净好用的页面。我的做法是左右结构：左边是文本输入区，右边是文件拖拽区，下方统一展示结果列表。

文本输入区用一个textarea，监听input事件，调用sha256Hex，结果展示在旁边的只读输入框里。文件区支持点击选择和拖拽，拖上去后逐文件计算，结果用表格或列表展示，每行包括文件名、文件大小、小写哈希。再加一个复制按钮，方便用户一键复制哈希值。

样式部分我通常不用任何UI框架，纯CSS写几行就够：圆角卡片、阴影、等宽字体显示哈希值。哈希值用等宽字体非常关键，因为0和O、1和l在等宽字体下不会混淆，用户肉眼对比起来压力小很多。

再做一个小优化：计算之前判断一下文件是不是空文件。空文件的SHA-256不是空字符串，而是一个固定值e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855。如果你不显示这个值，用户会以为代码出bug了。这个值是SHA-256对空字符串输入的输出，全世界的计算器结果都一样，是一个很好的自检值。

5. 实战避坑与排查实录：前端算哈希踩过的那些真实坑

5.1 crypto.subtle报undefined：先检查安全上下文

这是前端哈希生成器最经典的问题。我在一个内网项目里调试时遇到过：页面跑在http://192.168.x.x上，一打开控制台就发现crypto.subtle是undefined，所有哈希逻辑直接罢工。原因前面提过——Web Crypto API只在安全上下文暴露。

怎么确认？浏览器控制台执行：

console.log(window.isSecureContext); // true 或 false console.log(crypto.subtle); // 安全上下文里是CryptoSubtle对象

解决办法有三条路：

• 给内网环境配HTTPS证书，让页面走HTTPS。
• 开发调试时用localhost访问，浏览器对localhost永远视为安全上下文。
• 如果生产环境实在没法上HTTPS，就改用第三方库或自己实现哈希算法，绕过crypto.subtle依赖。

这个限制不是浏览器厂商故意刁难，而是因为Web Crypto API里包含强加密操作，非HTTPS环境下数据链路本身不安全，暴露强加密能力的意义会打折扣。理解这个背景，你在跟后端同事解释的时候就更有底气了。

5.2 中文乱码：TextEncoder到底做了什么

有个典型的错误写法是这样的：

const data = new Uint8Array(input.split('').map(c => c.charCodeAt(0)));

这段代码在英文输入下能算对，但输入中文"你好"就会得到和标准工具完全不同的哈希。原因在于charCodeAt返回的是UTF-16编码单元，而SHA-256标准定义的输入是字节序列，业内工具（比如sha256sum、在线工具）默认按UTF-8字节流处理。

"你"的UTF-8编码是E4 BD A0三个字节，但charCodeAt出来的是4F60这个UTF-16编码单元。两边字节流完全不一样，哈希自然对不上。解决方案就是我前面写的TextEncoder，它永远输出UTF-8字节流。注意TextEncoder是全局可用的标准接口，不需要额外引入。

顺带提醒：如果你在项目里做过"前端算哈希给后端校验"的需求，一定要和后端确认编码统一为UTF-8，同时小心BOM（字节序标记）。某些Windows编辑器保存的UTF-8文本会在文件头加三个字节的BOM，导致前端读出来的字节流和后端读取结果不一致，哈希自然对不上。

5.3 哈希短了一截：padStart少写了那个0

这个坑特别隐蔽。我用个真实例子说明：十六进制字节0x0a，在显示时要写作0a，但(10).toString(16)返回的是'a'。如果哈希结果里有两个这样的字节，最终字符串就少了两位，而且值完全错误。

我最初写工具时是这样写的：

return [...new Uint8Array(digest)].map(b => b.toString(16)).join('');

结果算出来的64位哈希，经常变成60或62个字符。排查了半天才发现是补零问题。加上padStart(2, '0')之后就完全正常了。

建议你写完哈希函数后，立刻用空字符串测试：sha256Hex('')应该返回e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855。这个固定值是最快的自检方式。

5.4 大文件内存爆掉和页面卡死

有一次我用整读的方式计算一个2GB的ISO文件哈希，页面直接崩溃了。原因很好理解：file.arrayBuffer()会把整个文件内容加载到内存，2GB文件就需要2GB以上内存，浏览器内存一压垮就开始崩溃。

前面已经给了增量哈希的轮子，这里再补充一点排查经验：如果你发现计算过程中浏览器内存只增不减，基本可以判断是整读文件导致的。页面卡顿则说明哈希运算跑在主线程上，需要迁到Worker。这两个问题往往同时出现，方案是"Worker + 分段读取 + 增量哈希"三位一体。

还有一个容易忽略的磁盘IO问题：分段读取时每段都调用arrayBuffer()，这是异步操作，但如果用的是同一个文件对象反复slice，不同浏览器对并发读取的实现不同，某些浏览器在高并发时会明显变慢。我的做法是控制在并发2到4段之间，不要一上来就把所有段同时读出来。

5.5 前后端哈希对不上：那些藏在细节里的差异

这个问题的排查顺序，我建议按下面这个清单来：

还有一个容易被忽略的细节：Windows和Unix换行符不同。如果你在Windows上写一个文件并计算哈希，传到Linux服务器上再次计算，如果文件内容本身没有做换行转换，哈希是一致的不变；但如果编辑器自动把LF转成了CRLF，哈希就会变。做文件比对的场景里遇到哈希不一致，先看两边的原始字节，再怀疑算法。

5.6 一个独家小技巧：用哈希做请求缓存键

最后分享一个我在实际业务里的玩法。在一个数据量比较大的列表页，前端每次拉取数据都会把查询条件和一个本地计算的哈希一起发给后端。后端如果发现哈希跟上一次一样，就直接返回304 Not Modified，不回传完整数据；只有哈希变了才返回最新数据。这样即使用户频繁点击刷新，只要数据没变，流量就非常省。

实现方式很简单：把查询参数按稳定顺序拼接成字符串，再算SHA-256作为缓存键。注意参数顺序要固定排序，否则{a:1,b:2}和{b:2,a:1}会因为字符串不同而产生不同哈希。这个场景充分体现了SHA-256确定性的价值：同一份数据，永远映射到同一个指纹；数据一旦变化，指纹立即变化。

写在最后：一点实际操作中的体会

做这个SHA-256生成器小工具，前后花了不到两天，但收获比预期的多。刚开始我只是想解决"临时算个哈希还得开命令行"的小麻烦，结果在排查各种哈希对不上的过程中，把编码、安全上下文、文件IO这些前端基础概念又系统梳理了一遍。我真实体会到，越是看起来简单的工具，背后的工程细节越值得琢磨。比如"前端算哈希"这个需求，表面上就一个函数的事，但真要支持任意文本、任意大小文件、不同网络环境的用户，要处理的问题比想象中多得多。

如果你打算自己动手写一个，我的建议是：先用Web Crypto API做基础版跑通，再手动算一遍算法流程加深理解，最后再补上大文件的Worker方案。三个版本做下来，你绝对能彻底理解SHA-256这回事。下次面试或者同事问起哈希算法，你就能拍着胸脯说"这个我不仅看过原理，还写过前端实现"。