尧图网页设计 
简介面向计算机相关专业学生与毕业设计场景的基于区块链的电子证据存证系统前端源码利用去中心化与不可篡改机制解决电子证据在真实性、完整性和可追溯性方面的核心痛点。前端界面简洁直观用户无需专业区块链背景即可完成上传、存证、管理及链上验证等操作。压缩包共78个文件以37个js逻辑脚本、17个less样式文件以及多张jpg、png界面资源为主另含项目配置、环境变量与说明文档整体大小仅5.13MB。工程目录包含src下的pages、services、utils、models、layouts等标准模块结构清晰便于局部修改与功能扩展。目前已有61人学习适合用于毕设选题、课程设计或区块链技术入门实践。通过研读源码可掌握区块链存证业务的前端实现思路同时学习现代Web项目的组织方式、状态管理和接口调用方法配套的README及配置文件还能辅助快速部署与二次开发为后续拓展数据可视化、证据核验等能力奠定基础。1. 基于区块链的电子证据存证系统前端不是UI是证据的入口防线做电子证据存证的人第一句话问我的往往不是链怎么选而是前端到底要干什么。我直接说结论在这个系统里前端决定了证据从产生那一刻起是不是干净、可信、可追溯的。它不只是让你上传个文件看个列表它要做的是把一个普通人手里的原始文件安全地加工成一份在区块链上有哈希、有签名、有时间戳、可验证的电子证据。适合谁适合做司法辅助、版权保护、电子合同、金融纠纷存证的团队——你们的核心诉求不是把数据存到链上而是一旦对簿公堂这份证据能自证清白。这篇笔记用一套实际交付过的前端方案把这个过程从头到尾拆开讲。2. 电子证据存证的前端为什么不是存文件那么简单2.1 证据的证明力取决于生成过程是否可信你手机上截一张聊天记录图用Photoshop改几个字再截图一次视觉上几乎没有差别。传统的电子数据鉴定里这种二次生成恰恰是证明力最弱的一类。区块链电子证据存证要解决的核心问题就是让证据的生成过程做到不被篡改、无法抵赖、全程留痕。前端作为证据的入口需要完成两个关键动作一是对原始文件做标准化的哈希计算二是对提交行为做用户的身份签名。哈希保证了内容没有被改过签名保证了是你本人提交的。这里有一个常见的认知误区很多人以为把整个文件塞进区块链就是存证了。实际上主流方案是把文件的哈希摘要和元数据上链原始文件存在你自己的存储服务里。区块链网络里每一笔交易都有Gas费或者写入成本存全量文件既不经济也没必要。哈希是一把指纹锁——文件内容任何一丁点变化哪怕是多加一个空格算出来的哈希值都会完全不同。2.2 前端在证据链中的位置采集、加工、上链、留档我一般会把前端在存证系统里的职责拆成四段。第一段是采集也就是用户选择文件、录入业务信息比如案件编号、证据类型、归属方。第二段是加工系统要对文件计算哈希、提取元数据、绑定业务信息生成一条结构化的证据条目。第三段是上链前端要把哈希、时间戳、用户身份发送到区块链网络。第四段是留档也就是把上链返回的交易哈希、区块高度、存证编号保存到前端本地记录里供后续查询和取证。这四个环节里前端最容易出问题的是第二段和第三段的衔接——尤其是一次典型的存证操作中你会遇到先算哈希再签名还是先签名再提交的顺序问题。正确顺序是先在浏览器里算文件哈希再把哈希和业务信息打包成待签名数据请用户确认后签名最后把签名后的凭证发上链。顺序反了证据就可能被人质疑内容在后端被换过。2.3 为什么说前端是不可信环境里的半可信层做电子证据存证你要理解一个现实浏览器运行在用户自己控制的设备上攻击者完全可以改内存、改JS代码、伪造请求。所以前端不能是唯一信任锚点。常见做法是前端做采集和展示后端做复核和背书两边同时持有记录上链前交叉校验。我见过一个翻车案例某团队前端直接取了一个当前时间戳写进证据里上链后发现用户电脑时间被改到了三个月前导致证据的时间线完全乱掉。血泪经验是——时间戳不要信前端本机时间要以后端服务器时间或者链上出块时间为准。前端可以做展示但判决时要能拿得出区块链网络自己的时间记录。3. 技术选型与前端工程结构从Vue3到多端适配的取舍3.1 为什么我选TypeScript Vue3而不是原生JS如果只是做一个企业内部的证据管理后台原生JS也不是不能用。但存证系统的前端要处理文件分片、哈希计算、加密签名、二进制协议这些场景下类型系统能帮你挡掉大量低级错误。我给用户做这套系统时选了Vue3 TypeScript原因有三个一是响应式数据流让证据状态的流转待处理、已签名、已上链、已校验可视化非常直观二是组合式API方便把哈希计算签名上链这些纯逻辑抽成独立模块方便复用测试三是团队招人时Vue3的TS经验比React更容易上手。现在一些司法链提供的官方前端SDK也优先支持TS定义文件跟ethers.js、web3.js的集成门槛更低。如果你是做移动端的uni-app方案也可以用同一套TS核心逻辑包到H5和小程序里但要注意——Web Worker在部分小程序环境里不可用大文件分片哈希策略得按平台降级。3.2 前端目录怎么组织代码才能扛住审计存证系统的代码要经受得住司法鉴定机构的审查所以目录结构从一开始就应该让证据流程一目了然而不是随便一个components文件夹堆到底。我一般会这样组织src/ api/ # 与后端网关交互的请求封装 core/ hash/ # 文件分片哈希 Worker sign/ # 用户身份签名 chain/ # 区块链网络连接与交易发送 store/ # 证据状态管理 views/ # 页面 upload/ # 证据上传 verify/ # 证据校验 archive/ # 存证记录列表这个结构里最重要的一点是把core/hash、core/sign、core/chain做成纯函数模块不接受任何UI状态。这样每一条证据的处理路径都清晰可控审查方可以直接看这三个模块来确认文件内容没有被二次处理。不要把签名逻辑散落到各个页面方法里——一旦散落审计时根本说不清楚证据路径上有没有被人动手脚。3.3 与后端和链上服务的接口约定前端不直接对接区块链节点的RPC端口中间要隔一层后端网关。这个网关负责三件事组装交易、管理用户身份、记录审计日志。前端只管向后端发标准HTTP请求拿到待签名数据后在本地签名再把签名结果回传。常见做法是定义一套存证APIPOST /api/evidence/prepare # 提交文件哈希与元数据返回待签名数据 POST /api/evidence/submit # 提交签名后的上链凭证 GET /api/evidence/{id} # 查询存证记录状态 GET /api/evidence/verify # 校验某个证据的链上存在性前端的chain模块只需要保存合约地址和链连接配置真正的私钥尽量放在后端安全环境里管理。如果你不想上自己的后端也可以用现成的BaaS服务但签名权限永远要控制在业务方手里——这是设计红线。4. 核心实现从文件选择到上链回执的完整代码流程4.1 大文件哈希计算的Web Worker方案电子证据文件往往不小——监控视频几百MB、邮件导出文件几十MB。直接在浏览器主线程里一次性读取并计算哈希页面会卡死用户以为程序坏了。我用的方案是Web Worker 分片读取 增量哈希。核心代码如下// src/core/hash/fileHash.worker.js importScripts(https://cdn.example.com/spark-md5.min.js); // 注意实际部署时应该把 spark-md5 打包进 worker这里用 importScripts 仅示意 self.onmessage function (e) { const { file, chunkSize } e.data; const spark new SparkMD5.ArrayBuffer(); let offset 0; const reader new FileReader(); reader.onerror () self.postMessage({ code: 1, message: 文件读取失败 }); reader.onload (event) { spark.append(event.target.result); offset event.target.result.byteLength; self.postMessage({ code: 0, progress: Math.min(offset / file.size, 1) }); if (offset file.size) { readNext(); } else { const hash spark.end(); self.postMessage({ code: 2, hash, size: file.size }); } }; function readNext() { const slice file.slice(offset, offset chunkSize); reader.readAsArrayBuffer(slice); } readNext(); };主线程这边这样调用// src/core/hash/useFileHash.ts export function computeFileHash(file: File): Promisestring { return new Promise((resolve, reject) { const worker new Worker(new URL(./fileHash.worker.js, import.meta.url)); const chunkSize 2 * 1024 * 1024; // 2MB 一片 worker.postMessage({ file, chunkSize }); worker.onmessage (e) { const msg e.data; if (msg.code 2) { worker.terminate(); resolve(msg.hash); } else if (msg.code 1) { worker.terminate(); reject(new Error(msg.message)); } // 进度可以在这里更新到 store代码略 }; worker.onerror (err) { worker.terminate(); reject(err); }; }); }这里有两个关键点你需要记牢。第一分片大小设为2MB是经验值——太小会导致FileReader反复调度性能反而下降太大则Worker单次处理时间较长进度更新不平滑。第二SparkMD5的append必须接收ArrayBuffer不能直接传Blob所以每次都要走readAsArrayBuffer这一步。哈希算法选型上SHA-256其实比MD5更适合司法场景因为MD5在理论上有碰撞攻击的可能性。如果你用Node.js的crypto做直接用createHash(sha256)即可浏览器端推荐用Web Crypto API的crypto.subtle.digest它是原生的、异步的、不需要额外库。不过Web Crypto不支持增量流式计算大文件还是要走分片——我在项目里是把每个分片哈希再整体加盐哈希一次等于做了一棵简化的哈希树。具体做法是把每个分片计算出独立SHA-256再对这些分片哈希做二次哈希得到根哈希。4.2 签名与上链把哈希变成链上凭证文件哈希算好了接下来是和区块链交互。以以太坊系链为例前端通过ethers.js连接合约。要注意这里前端用的钱包私钥应该只是业务签名钥不是管理链上资金的私钥。存证合约一般只记录哈希、提交人地址和时间戳不涉及转账。// src/core/chain/evidenceContract.ts import { ethers } from ethers; // 用一个简化版的合约 ABI——真实部署时合约由链上服务方提供统一地址 const EVIDENCE_ABI [ function storeEvidence(bytes32 hash, string memory metadata) public returns (uint256), function getEvidence(uint256 id) public view returns (address submitter, bytes32 hash, uint256 timestamp), ]; export async function storeEvidenceOnChain( providerUrl: string, contractAddress: string, privateKey: string, fileHash: string, metadata: string ) { const provider new ethers.JsonRpcProvider(providerUrl); const wallet new ethers.Wallet(privateKey, provider); const contract new ethers.Contract(contractAddress, EVIDENCE_ABI, wallet); const hashBytes ethers.keccak256(ethers.toUtf8Bytes(fileHash)); const tx await contract.storeEvidence(hashBytes, metadata); const receipt await tx.wait(); return { txHash: receipt.hash, blockNumber: receipt.blockNumber, }; }这里有一个值得说的细节合约接收的参数是bytes32而前端拿到的是字符串哈希。ethers.keccak256(ethers.toUtf8Bytes(fileHash))这个写法等于对哈希字符串做了一次二次哈希。这种做法是故意的——目的是防止有人把原始文件哈希直接原样上链导致长度溢出同时给链上记录加一重混淆。但是链上记录和原哈希之间的关联必须在后端存一份映射表否则取证时无法从链上值反推原始文件。签名动作在真实系统里不是直接拿私钥调的而是通过弹出待签名数据让用户确认。前端负责渲染这段数据// src/core/sign/prepareSignature.ts export function buildSignMessage(payload: { fileHash: string; fileName: string; fileSize: number; timestamp: string; userId: string; }) { return [ 我将对以下电子证据进行区块链存证, 文件名${payload.fileName}, 文件大小${payload.fileSize} 字节, SHA-256${payload.fileHash}, 提交时间${payload.timestamp}, 提交人${payload.userId}, ].join(\n); }用户看到的是一段人类可读的文字签的是这段文字对应的哈希而不是一串乱码。这项设计是为了避免盲签——如果用户不知道自己签了什么事后主张被诱导签名证据效力就大打折扣。4.3 上链成功不等于交易被打包要等确认我见到不止一个团队调用合约方法后拿到tx.hash就立刻显示存证成功。这是大坑。区块链交易有四个状态已广播、已打包、已确认、已最终固化。以太坊系推荐至少等1个确认块联盟链看共识策略——有些链即时确认有些也要等一轮共识。实践中我一般这样处理// 在 storeEvidenceOnChain 里 tx.wait() 已经是标准做法 // 这里补充一下可选的确认等待策略 const receipt await tx.wait(1); // 等待1个区块确认如果链比较慢等待期间要给用户一个合理的交互——不要让用户干等也不要让他以为失败了。正确姿势是显示已提交上链等待网络确认中并附带交易哈希供后续在区块链浏览器里查。5. 电子证据存证前端常见问题排查五个真实翻车点5.1 文件明明传上来了为什么一直显示转圈——分片哈希死循环现象小文件秒成功大文件200MB一直卡在处理中CPU占用率极高页面假死。原因Web Worker在计算超大文件时主线程向Worker发送file对象没有问题但如果你在Worker内每次重新new FileReader()并且文件的分片逻辑里offset没有正确累加就会陷入死循环。另外importScripts如果加载的是外部CDN脚本Worker网络请求被浏览器安全策略拦截时Worker会直接报错但主线程不一定能捕获到。解决确保Worker内使用self.onmessage事件的监听器只创建一次FileReader不要在readNext里重复创建确定分片读取的边界条件在offset file.size时结束。外部脚本要打包到Worker文件里不要依赖CDN。5.2 前端算的哈希后端校验不一致——算法或编码不一致现象前端提交证据后端复核时算出完全不同的哈希存证流程中断。原因最常见的是字符编码问题。前端把文件内容以UTF-8文本方式读取后端以二进制方式读取个别字节转换出错或者前端用File.text()读文本文件后端用fs.readFileSync读Buffer两者对BOM头的处理不同。另一个低级错误是前端把文件读成Base64后再哈希后端是直接用原始字节哈希。解决统一约定哈希的对象永远是原始文件字节流。前端必须用ArrayBuffer读文件后端用Buffer两边加一个约定——先对文件内容做二进制读取再做SHA-256。测试时用固定的测试文件比对两边输出。5.3 明明上链了取证平台却查不到——交易哈希与存证编号混淆现象前端拿到了存证编号但去区块链浏览器上查txHash查不到或者查到了但是证据内容对不上。原因前端把后端返回的存证编号业务主键当成了链上交易哈希存进数据库。取证时拿着业务编号去查链自然查不到。解决前端展示和落地存储时把三个值彻底分开存证编号业务系统内唯一、交易哈希链上唯一、区块高度出块位置。展示给用户时三个字段并列不要混在一起。数据库设计时加唯一索引约束防止重复提交造成的编号污染。5.4 私钥存在localStorage被XSS一锅端——安全假设崩塌现象测试人员用一个简单的存储型XSS脚本就把用户存证身份和私钥全拿走了。原因为了图方便把签名用的私钥存在了localStorage而应用里某个富文本字段没有做转义被注入恶意脚本。解决私钥永远不能落到localStorage或者sessionStorage。存放方式至少做到两层私钥放后端托管的密钥服务里前端只持有短时效的签名授权token前端如果必须持有私钥用crypto.subtle的非对称加密方式在内存中使用页面刷新即失效。同时所有用户输入字段统一做HTML转义并配置CSP策略白名单。5.5 时间戳是开奖号——用户改了本地时间证据依然被采纳——信任链断裂现象某用户为了掩盖迟交证据的事实把自己电脑时间改到了前一天前端记录的时间戳跟着变了系统没有提示。原因前端采集的Date.now()是本地时钟可信度为零。解决时间戳一律以后端返回的服务器时间为准并同时记录一个链上出块时间。前端只能做展示。如果业务允许在签名消息里必须包含后端下发的时间戳前端签名它、后端也签名它两边对齐才能保证提交时间不可抵赖。6. 最后一个实战技巧怎么验证你的前端上链回执是真的很多人做到上链成功就觉得完事了但真正的存证系统最后一公里是取证时的自证。前端要能在几秒内回答三个问题这条链上记录存在吗它的哈希和我手里的文件一致吗它是什么时候被写入的我给你一个验证流程第一步从receipt.blockNumber或receipt.transactionHash拿到底层链参数为一个独立的验证页面提供一个入口输入文件名或存证编号后自动反查。第二步调getEvidence从合约读取链上哈希和本地重新对文件算出的哈希比对。第三步同时展示前端提交时的签名凭证、后端审计日志里的时间戳、链上出块时间三者一条时间线对齐。代码实现可以做成一个独立页面// views/VerifyEvidence.vue 行为逻辑示意 async function verifyEvidence(file: File, evidenceId: string) { const localHash await computeFileHash(file); // 重新计算文件哈希 const onChainData await queryEvidenceById(evidenceId); // 读取链上记录 const match localHash onChainData.fileHash; // 哈希比对 return { match, localHash, onChainHash: onChainData.fileHash, chainConfirmedAt: onChainData.timestamp, }; }验证页必须做到拒绝自作主张——不要只显示验证通过要把对比的两个哈希值都明文展示出来让使用的人自己能看到是否一致。我自己的习惯是每个存证记录在成功后都留一个验证入口按钮用户随时可以对同一个文件反复做校验——文件每次改完再验证都会得到不同的哈希这才是区块链存证的真正价值所在它给了你一个永不撒谎的分身。希望帮到你。本文还有配套的精品资源点击获取 区块链电子证据存证前端实战：从哈希计算到上链验证
简介面向计算机相关专业学生与毕业设计场景的基于区块链的电子证据存证系统前端源码利用去中心化与不可篡改机制解决电子证据在真实性、完整性和可追溯性方面的核心痛点。前端界面简洁直观用户无需专业区块链背景即可完成上传、存证、管理及链上验证等操作。压缩包共78个文件以37个js逻辑脚本、17个less样式文件以及多张jpg、png界面资源为主另含项目配置、环境变量与说明文档整体大小仅5.13MB。工程目录包含src下的pages、services、utils、models、layouts等标准模块结构清晰便于局部修改与功能扩展。目前已有61人学习适合用于毕设选题、课程设计或区块链技术入门实践。通过研读源码可掌握区块链存证业务的前端实现思路同时学习现代Web项目的组织方式、状态管理和接口调用方法配套的README及配置文件还能辅助快速部署与二次开发为后续拓展数据可视化、证据核验等能力奠定基础。1. 基于区块链的电子证据存证系统前端不是UI是证据的入口防线做电子证据存证的人第一句话问我的往往不是链怎么选而是前端到底要干什么。我直接说结论在这个系统里前端决定了证据从产生那一刻起是不是干净、可信、可追溯的。它不只是让你上传个文件看个列表它要做的是把一个普通人手里的原始文件安全地加工成一份在区块链上有哈希、有签名、有时间戳、可验证的电子证据。适合谁适合做司法辅助、版权保护、电子合同、金融纠纷存证的团队——你们的核心诉求不是把数据存到链上而是一旦对簿公堂这份证据能自证清白。这篇笔记用一套实际交付过的前端方案把这个过程从头到尾拆开讲。2. 电子证据存证的前端为什么不是存文件那么简单2.1 证据的证明力取决于生成过程是否可信你手机上截一张聊天记录图用Photoshop改几个字再截图一次视觉上几乎没有差别。传统的电子数据鉴定里这种二次生成恰恰是证明力最弱的一类。区块链电子证据存证要解决的核心问题就是让证据的生成过程做到不被篡改、无法抵赖、全程留痕。前端作为证据的入口需要完成两个关键动作一是对原始文件做标准化的哈希计算二是对提交行为做用户的身份签名。哈希保证了内容没有被改过签名保证了是你本人提交的。这里有一个常见的认知误区很多人以为把整个文件塞进区块链就是存证了。实际上主流方案是把文件的哈希摘要和元数据上链原始文件存在你自己的存储服务里。区块链网络里每一笔交易都有Gas费或者写入成本存全量文件既不经济也没必要。哈希是一把指纹锁——文件内容任何一丁点变化哪怕是多加一个空格算出来的哈希值都会完全不同。2.2 前端在证据链中的位置采集、加工、上链、留档我一般会把前端在存证系统里的职责拆成四段。第一段是采集也就是用户选择文件、录入业务信息比如案件编号、证据类型、归属方。第二段是加工系统要对文件计算哈希、提取元数据、绑定业务信息生成一条结构化的证据条目。第三段是上链前端要把哈希、时间戳、用户身份发送到区块链网络。第四段是留档也就是把上链返回的交易哈希、区块高度、存证编号保存到前端本地记录里供后续查询和取证。这四个环节里前端最容易出问题的是第二段和第三段的衔接——尤其是一次典型的存证操作中你会遇到先算哈希再签名还是先签名再提交的顺序问题。正确顺序是先在浏览器里算文件哈希再把哈希和业务信息打包成待签名数据请用户确认后签名最后把签名后的凭证发上链。顺序反了证据就可能被人质疑内容在后端被换过。2.3 为什么说前端是不可信环境里的半可信层做电子证据存证你要理解一个现实浏览器运行在用户自己控制的设备上攻击者完全可以改内存、改JS代码、伪造请求。所以前端不能是唯一信任锚点。常见做法是前端做采集和展示后端做复核和背书两边同时持有记录上链前交叉校验。我见过一个翻车案例某团队前端直接取了一个当前时间戳写进证据里上链后发现用户电脑时间被改到了三个月前导致证据的时间线完全乱掉。血泪经验是——时间戳不要信前端本机时间要以后端服务器时间或者链上出块时间为准。前端可以做展示但判决时要能拿得出区块链网络自己的时间记录。3. 技术选型与前端工程结构从Vue3到多端适配的取舍3.1 为什么我选TypeScript Vue3而不是原生JS如果只是做一个企业内部的证据管理后台原生JS也不是不能用。但存证系统的前端要处理文件分片、哈希计算、加密签名、二进制协议这些场景下类型系统能帮你挡掉大量低级错误。我给用户做这套系统时选了Vue3 TypeScript原因有三个一是响应式数据流让证据状态的流转待处理、已签名、已上链、已校验可视化非常直观二是组合式API方便把哈希计算签名上链这些纯逻辑抽成独立模块方便复用测试三是团队招人时Vue3的TS经验比React更容易上手。现在一些司法链提供的官方前端SDK也优先支持TS定义文件跟ethers.js、web3.js的集成门槛更低。如果你是做移动端的uni-app方案也可以用同一套TS核心逻辑包到H5和小程序里但要注意——Web Worker在部分小程序环境里不可用大文件分片哈希策略得按平台降级。3.2 前端目录怎么组织代码才能扛住审计存证系统的代码要经受得住司法鉴定机构的审查所以目录结构从一开始就应该让证据流程一目了然而不是随便一个components文件夹堆到底。我一般会这样组织src/ api/ # 与后端网关交互的请求封装 core/ hash/ # 文件分片哈希 Worker sign/ # 用户身份签名 chain/ # 区块链网络连接与交易发送 store/ # 证据状态管理 views/ # 页面 upload/ # 证据上传 verify/ # 证据校验 archive/ # 存证记录列表这个结构里最重要的一点是把core/hash、core/sign、core/chain做成纯函数模块不接受任何UI状态。这样每一条证据的处理路径都清晰可控审查方可以直接看这三个模块来确认文件内容没有被二次处理。不要把签名逻辑散落到各个页面方法里——一旦散落审计时根本说不清楚证据路径上有没有被人动手脚。3.3 与后端和链上服务的接口约定前端不直接对接区块链节点的RPC端口中间要隔一层后端网关。这个网关负责三件事组装交易、管理用户身份、记录审计日志。前端只管向后端发标准HTTP请求拿到待签名数据后在本地签名再把签名结果回传。常见做法是定义一套存证APIPOST /api/evidence/prepare # 提交文件哈希与元数据返回待签名数据 POST /api/evidence/submit # 提交签名后的上链凭证 GET /api/evidence/{id} # 查询存证记录状态 GET /api/evidence/verify # 校验某个证据的链上存在性前端的chain模块只需要保存合约地址和链连接配置真正的私钥尽量放在后端安全环境里管理。如果你不想上自己的后端也可以用现成的BaaS服务但签名权限永远要控制在业务方手里——这是设计红线。4. 核心实现从文件选择到上链回执的完整代码流程4.1 大文件哈希计算的Web Worker方案电子证据文件往往不小——监控视频几百MB、邮件导出文件几十MB。直接在浏览器主线程里一次性读取并计算哈希页面会卡死用户以为程序坏了。我用的方案是Web Worker 分片读取 增量哈希。核心代码如下// src/core/hash/fileHash.worker.js importScripts(https://cdn.example.com/spark-md5.min.js); // 注意实际部署时应该把 spark-md5 打包进 worker这里用 importScripts 仅示意 self.onmessage function (e) { const { file, chunkSize } e.data; const spark new SparkMD5.ArrayBuffer(); let offset 0; const reader new FileReader(); reader.onerror () self.postMessage({ code: 1, message: 文件读取失败 }); reader.onload (event) { spark.append(event.target.result); offset event.target.result.byteLength; self.postMessage({ code: 0, progress: Math.min(offset / file.size, 1) }); if (offset file.size) { readNext(); } else { const hash spark.end(); self.postMessage({ code: 2, hash, size: file.size }); } }; function readNext() { const slice file.slice(offset, offset chunkSize); reader.readAsArrayBuffer(slice); } readNext(); };主线程这边这样调用// src/core/hash/useFileHash.ts export function computeFileHash(file: File): Promisestring { return new Promise((resolve, reject) { const worker new Worker(new URL(./fileHash.worker.js, import.meta.url)); const chunkSize 2 * 1024 * 1024; // 2MB 一片 worker.postMessage({ file, chunkSize }); worker.onmessage (e) { const msg e.data; if (msg.code 2) { worker.terminate(); resolve(msg.hash); } else if (msg.code 1) { worker.terminate(); reject(new Error(msg.message)); } // 进度可以在这里更新到 store代码略 }; worker.onerror (err) { worker.terminate(); reject(err); }; }); }这里有两个关键点你需要记牢。第一分片大小设为2MB是经验值——太小会导致FileReader反复调度性能反而下降太大则Worker单次处理时间较长进度更新不平滑。第二SparkMD5的append必须接收ArrayBuffer不能直接传Blob所以每次都要走readAsArrayBuffer这一步。哈希算法选型上SHA-256其实比MD5更适合司法场景因为MD5在理论上有碰撞攻击的可能性。如果你用Node.js的crypto做直接用createHash(sha256)即可浏览器端推荐用Web Crypto API的crypto.subtle.digest它是原生的、异步的、不需要额外库。不过Web Crypto不支持增量流式计算大文件还是要走分片——我在项目里是把每个分片哈希再整体加盐哈希一次等于做了一棵简化的哈希树。具体做法是把每个分片计算出独立SHA-256再对这些分片哈希做二次哈希得到根哈希。4.2 签名与上链把哈希变成链上凭证文件哈希算好了接下来是和区块链交互。以以太坊系链为例前端通过ethers.js连接合约。要注意这里前端用的钱包私钥应该只是业务签名钥不是管理链上资金的私钥。存证合约一般只记录哈希、提交人地址和时间戳不涉及转账。// src/core/chain/evidenceContract.ts import { ethers } from ethers; // 用一个简化版的合约 ABI——真实部署时合约由链上服务方提供统一地址 const EVIDENCE_ABI [ function storeEvidence(bytes32 hash, string memory metadata) public returns (uint256), function getEvidence(uint256 id) public view returns (address submitter, bytes32 hash, uint256 timestamp), ]; export async function storeEvidenceOnChain( providerUrl: string, contractAddress: string, privateKey: string, fileHash: string, metadata: string ) { const provider new ethers.JsonRpcProvider(providerUrl); const wallet new ethers.Wallet(privateKey, provider); const contract new ethers.Contract(contractAddress, EVIDENCE_ABI, wallet); const hashBytes ethers.keccak256(ethers.toUtf8Bytes(fileHash)); const tx await contract.storeEvidence(hashBytes, metadata); const receipt await tx.wait(); return { txHash: receipt.hash, blockNumber: receipt.blockNumber, }; }这里有一个值得说的细节合约接收的参数是bytes32而前端拿到的是字符串哈希。ethers.keccak256(ethers.toUtf8Bytes(fileHash))这个写法等于对哈希字符串做了一次二次哈希。这种做法是故意的——目的是防止有人把原始文件哈希直接原样上链导致长度溢出同时给链上记录加一重混淆。但是链上记录和原哈希之间的关联必须在后端存一份映射表否则取证时无法从链上值反推原始文件。签名动作在真实系统里不是直接拿私钥调的而是通过弹出待签名数据让用户确认。前端负责渲染这段数据// src/core/sign/prepareSignature.ts export function buildSignMessage(payload: { fileHash: string; fileName: string; fileSize: number; timestamp: string; userId: string; }) { return [ 我将对以下电子证据进行区块链存证, 文件名${payload.fileName}, 文件大小${payload.fileSize} 字节, SHA-256${payload.fileHash}, 提交时间${payload.timestamp}, 提交人${payload.userId}, ].join(\n); }用户看到的是一段人类可读的文字签的是这段文字对应的哈希而不是一串乱码。这项设计是为了避免盲签——如果用户不知道自己签了什么事后主张被诱导签名证据效力就大打折扣。4.3 上链成功不等于交易被打包要等确认我见到不止一个团队调用合约方法后拿到tx.hash就立刻显示存证成功。这是大坑。区块链交易有四个状态已广播、已打包、已确认、已最终固化。以太坊系推荐至少等1个确认块联盟链看共识策略——有些链即时确认有些也要等一轮共识。实践中我一般这样处理// 在 storeEvidenceOnChain 里 tx.wait() 已经是标准做法 // 这里补充一下可选的确认等待策略 const receipt await tx.wait(1); // 等待1个区块确认如果链比较慢等待期间要给用户一个合理的交互——不要让用户干等也不要让他以为失败了。正确姿势是显示已提交上链等待网络确认中并附带交易哈希供后续在区块链浏览器里查。5. 电子证据存证前端常见问题排查五个真实翻车点5.1 文件明明传上来了为什么一直显示转圈——分片哈希死循环现象小文件秒成功大文件200MB一直卡在处理中CPU占用率极高页面假死。原因Web Worker在计算超大文件时主线程向Worker发送file对象没有问题但如果你在Worker内每次重新new FileReader()并且文件的分片逻辑里offset没有正确累加就会陷入死循环。另外importScripts如果加载的是外部CDN脚本Worker网络请求被浏览器安全策略拦截时Worker会直接报错但主线程不一定能捕获到。解决确保Worker内使用self.onmessage事件的监听器只创建一次FileReader不要在readNext里重复创建确定分片读取的边界条件在offset file.size时结束。外部脚本要打包到Worker文件里不要依赖CDN。5.2 前端算的哈希后端校验不一致——算法或编码不一致现象前端提交证据后端复核时算出完全不同的哈希存证流程中断。原因最常见的是字符编码问题。前端把文件内容以UTF-8文本方式读取后端以二进制方式读取个别字节转换出错或者前端用File.text()读文本文件后端用fs.readFileSync读Buffer两者对BOM头的处理不同。另一个低级错误是前端把文件读成Base64后再哈希后端是直接用原始字节哈希。解决统一约定哈希的对象永远是原始文件字节流。前端必须用ArrayBuffer读文件后端用Buffer两边加一个约定——先对文件内容做二进制读取再做SHA-256。测试时用固定的测试文件比对两边输出。5.3 明明上链了取证平台却查不到——交易哈希与存证编号混淆现象前端拿到了存证编号但去区块链浏览器上查txHash查不到或者查到了但是证据内容对不上。原因前端把后端返回的存证编号业务主键当成了链上交易哈希存进数据库。取证时拿着业务编号去查链自然查不到。解决前端展示和落地存储时把三个值彻底分开存证编号业务系统内唯一、交易哈希链上唯一、区块高度出块位置。展示给用户时三个字段并列不要混在一起。数据库设计时加唯一索引约束防止重复提交造成的编号污染。5.4 私钥存在localStorage被XSS一锅端——安全假设崩塌现象测试人员用一个简单的存储型XSS脚本就把用户存证身份和私钥全拿走了。原因为了图方便把签名用的私钥存在了localStorage而应用里某个富文本字段没有做转义被注入恶意脚本。解决私钥永远不能落到localStorage或者sessionStorage。存放方式至少做到两层私钥放后端托管的密钥服务里前端只持有短时效的签名授权token前端如果必须持有私钥用crypto.subtle的非对称加密方式在内存中使用页面刷新即失效。同时所有用户输入字段统一做HTML转义并配置CSP策略白名单。5.5 时间戳是开奖号——用户改了本地时间证据依然被采纳——信任链断裂现象某用户为了掩盖迟交证据的事实把自己电脑时间改到了前一天前端记录的时间戳跟着变了系统没有提示。原因前端采集的Date.now()是本地时钟可信度为零。解决时间戳一律以后端返回的服务器时间为准并同时记录一个链上出块时间。前端只能做展示。如果业务允许在签名消息里必须包含后端下发的时间戳前端签名它、后端也签名它两边对齐才能保证提交时间不可抵赖。6. 最后一个实战技巧怎么验证你的前端上链回执是真的很多人做到上链成功就觉得完事了但真正的存证系统最后一公里是取证时的自证。前端要能在几秒内回答三个问题这条链上记录存在吗它的哈希和我手里的文件一致吗它是什么时候被写入的我给你一个验证流程第一步从receipt.blockNumber或receipt.transactionHash拿到底层链参数为一个独立的验证页面提供一个入口输入文件名或存证编号后自动反查。第二步调getEvidence从合约读取链上哈希和本地重新对文件算出的哈希比对。第三步同时展示前端提交时的签名凭证、后端审计日志里的时间戳、链上出块时间三者一条时间线对齐。代码实现可以做成一个独立页面// views/VerifyEvidence.vue 行为逻辑示意 async function verifyEvidence(file: File, evidenceId: string) { const localHash await computeFileHash(file); // 重新计算文件哈希 const onChainData await queryEvidenceById(evidenceId); // 读取链上记录 const match localHash onChainData.fileHash; // 哈希比对 return { match, localHash, onChainHash: onChainData.fileHash, chainConfirmedAt: onChainData.timestamp, }; }验证页必须做到拒绝自作主张——不要只显示验证通过要把对比的两个哈希值都明文展示出来让使用的人自己能看到是否一致。我自己的习惯是每个存证记录在成功后都留一个验证入口按钮用户随时可以对同一个文件反复做校验——文件每次改完再验证都会得到不同的哈希这才是区块链存证的真正价值所在它给了你一个永不撒谎的分身。希望帮到你。本文还有配套的精品资源点击获取