简介基于区块链的电子证据存证系统前端源码面向计算机相关专业的在校学生、教师及企业开发者适用于毕业设计、课程设计、项目初期立项演示等场景。系统通过去中心化存储与密码学保护确保电子证据上链后不可篡改、可追溯前端界面简洁直观便于普通用户快速完成上传与存证操作。压缩包内含78个文件约5.13MB包含37个JavaScript脚本、17个LESS样式、9张JPG与4张PNG图片以及工程配置文件与说明文档目录按功能模块划分可快速定位页面、组件、服务与工具模块。当前已有61人学习。通过阅读源码可以理解区块链存证业务的完整前端实现路径包括组件化页面搭建、状态管理、接口封装与交互反馈搭配文档资料也能掌握现代前端构建工具与代码规范为自主开发或继续拓展区块链应用打下基础。1. 区块链电子证据存证系统的真正工作量人消费者在前端而不是链条一套基于区块链的电子证据存证系统拿到手时往往是一个带合约目录的仓库加一个前端工程压缩包。可能出乎大多数人意料链上的智能合约只用一小段代码就能写完而前端源码里的证据采集、哈希计算、时间戳格式化、验真页面、异常链路处理加起来占了整个存证系统八成以上的工程量。前端不是展示存证结果的壳而是证据从产生到上链再到事后比对的唯一边界。这篇笔记围绕底层区块链电子证据存证系统的前端源码展开适合两类人一类是想把这个方向跑通的开发者另一类是采购了源码但不知道如何验证和二次开发的负责人。会先从证据完整性为什么落在前端讲起再给出一套浏览器端可复现的最小闭环代码然后逐个拆参数、踩坑、隐私边界最后给出验收级的验证报告做法。希望帮到你。2. 为什么要用前端算 Hash而不是把整个文件扔上链很多人第一次接触存证系统时会把“上链”理解成“把所有证据文件放上区块链”。这个直觉是反的而且会让整个系统变得不可用。区块链不适合存大文件原因有两个一是区块容量和交易成本不允许二是绝大多数证据场景需要保护隐私。真正落到链上的是文件的数字指纹。谁算这个指纹就成了信任链的第一环。2.1 证据完整性的前提文件与哈希分离电子证据要被采信核心诉求是能够证明“这份文件在某时间点存在并且此后没有被改动”。块链能保证的是写入后的数据不可篡改它不能保证写入前数据是正确的。所以存证系统分成两个阶段先把文件映射成一串固定长度的哈希再把哈希写入链上。链上哈希等于一个锚点后续任何时刻只要重新计算文件哈希、与锚点比对一致就能反推文件没有被改过。这里有一个容易被忽略的细节Hash 计算必须在拿到原始文件的“入口处”完成并且计算过程不能被中间层替换。如果后端服务器接收文件后计算哈希那后端就变成了一个可被攻击的信任黑匣子如果前端在浏览器里计算那文件从用户手里到哈希生成这个闭环是完整可见的。所以存证系统的前端源码里第一步一定是“前端本地计算 SHA-256”而不是上传文件后等后端返回。2.2 浏览器端 SHA-256 指纹计算的最小实现Web 标准提供了 Web Crypto API在浏览器环境里可以直接算 SHA-256不需要引入额外库。下面这段代码是一个通用的文件指纹生成函数也是前端源码里最基础的一个模块。// 把一个 File 对象转换为 SHA-256 十六进制字符串 async function computeFileHash(file) { // 1. 将文件读成 ArrayBuffer const buffer await file.arrayBuffer(); // 2. 用 Web Crypto API 计算摘要选择 SHA-256 const digest await crypto.subtle.digest(SHA-256, buffer); // 3. 把 ArrayBuffer 转成 hex 字符串方便展示和上链 const bytes new Uint8Array(digest); let hex ; for (let i 0; i bytes.length; i) { hex bytes[i].toString(16).padStart(2, 0); } return hex.toLowerCase(); }代码的逻辑分三步读取文件二进制内容、调用系统级加密模块计算摘要、把摘要转成十六进制字符串。关键点是crypto.subtle.digest它是由操作系统底层的加密库实现的比纯 JavaScript 库性能好而且随机性和安全性有保障。bytes[i].toString(16).padStart(2, 0)是很多新手会写错的地方。每个字节转成十六进制后可能只有一位比如0x0a如果不去补零拼出来的哈希看起来也是 64 位但内容会错位。这个补零动作必须保留否则同一个文件在不同机器上会算出不同的哈希现场演示时直接翻车。这个接口需要两个环境前提页面必须在 HTTPS 或 localhost 下运行浏览器需要支持 Web Crypto。Chrome、Edge、Firefox 最新版本都没问题。整个计算在本地完成文件没有被上传这一步也是隐私保护的第一道闸。2.3 前端 SDK 与链上交互方式的选型边界存证前端要和区块链节点打交道常见方式有两条直接调用节点 JSON-RPC 接口或者使用ethers.js/web3.js这类封装库。直接调 JSON-RPC 只适合调试场景它需要自己拼交易、管理私钥、处理签名代码量大且容易出错。生产环境我一般用ethers.js原因有三个它内置了助记词派生、私钥管理和交易签名逻辑它的合约调用接口允许只传参数而不手写数据编码它的事件监听机制对验真场景很友好。前端源码里如果你看到web3.js是旧项目遗留也可以继续用但新工程建议直接切到ethers.jsv6。选型还有一个边界要划清楚前端只做“构造交易和展示结果”不做“共识”和“验证区块合法性”。有些源码为了炫技会试图在前端遍历区块这是没有必要的。前端的职责范围是采集文件指纹、构造存证交易、等待链上确认、拉取链上证据哈希做比对。超出这些范围的功能要么引入沉重的依赖要么让浏览器直接卡死。3. 可复现的最小存证闭环从证据采集、上链到本地验真这一章的目标是让你能在一个空浏览器页面里把“采集文件 → 计算哈希 → 写入链上 → 事后验真”这四步完整跑通。不依赖任何后端服务前端源码只需三个文件和若干依赖。3.1 证据登记的数据结构与时间约定存证不是只存一个哈希还需要附带必要的元数据让后续可以追溯“这串哈希对应哪个证据、由谁在何时提交”。但元数据的取舍很讲究字段太少举证时说不清来源字段太多隐私风险和上链费用同步上升。我通常采用的证据登记结构只有五个字段。字段类型说明evidenceHashbytes32文件 SHA-256转成 bytes32 后上链timestampuint256取证时刻的毫秒级 Unix 时间戳evidenceTypestring可选值contract、image、video、logdescriptionHashbytes32业务描述信息的哈希原件内容不上链submitteraddress提交人地址由前端签名自动填充这里有一个实践层面的时间约定不要使用设备本地时间。设备时间可以被用户修改会导致证据时间线不可信。常见做法是拿到后端或链上的可信时间前端源码里的时间戳统一取Math.floor(Date.now() / 1000)只是开发阶段的临时方案。正式系统应当从可信时间接口拉取当前时间再写入登记结构。3.2 用 ethers.js 提交交易的标准流程下面的代码是一个完整的“文件上链”前端函数。它使用ethers.jsv6结合上一章的文件哈希模块把哈希提交给链上合约。import { ethers } from ethers; // 合约 ABI 只保留存证相关的两个方法storeEvidence 和 verifyEvidence const abi [ function storeEvidence(bytes32 evidenceHash, uint256 timestamp, string memory evidenceType, bytes32 descriptionHash) public returns (bool), function verifyEvidence(bytes32 evidenceHash) public view returns (bool exists, uint256 timestamp, string memory evidenceType, address submitter), ]; async function storeEvidence(file, evidenceType, description) { // 计算原文哈希后续所有操作都围绕这个哈希进行 const evidenceHash await computeFileHash(file); // 连接浏览器钱包MetaMask、imToken 等标准钱包均适用 const provider new ethers.BrowserProvider(window.ethereum); const signer await provider.getSigner(); // 合约地址来自部署合约时的返回值需替换为你自己的地址 const contractAddress 0xYourContractAddressHere; const contract new ethers.Contract(contractAddress, abi, signer); // 计算描述信息的哈希避免把明文业务描述上链 const encoder new TextEncoder(); const descDigest await crypto.subtle.digest(SHA-256, encoder.encode(description)); const descriptionHash ethers.hexlify(descDigest); // 构造并发送交易gas 参数根据链的情况调整 const tx await contract.storeEvidence( ethers.hexlify(ethers.getBytes(0x evidenceHash)), Math.floor(Date.now() / 1000), evidenceType, ethers.hexlify(ethers.getBytes(descriptionHash)), ); // 等待上链确认回执里可以拿到区块号和交易哈希 const receipt await tx.wait(); return { txHash: receipt.hash, blockNumber: receipt.blockNumber, evidenceHash, }; }流程分五段文件哈希、连接钱包、初始化合约对象、提交交易、等待确认。ethers.BrowserProvider是 v6 连接浏览器钱包的统一入口它会把window.ethereum封装成一个可读链上状态的 provider。两个关键参数需要注意。evidenceHash转成bytes32时必须用ethers.hexlify(ethers.getBytes(0x evidenceHash))原因是我们拿到的哈希是 32 字节但 Hex 字符串是 64 个字符直接传字符串会发生类型不匹配。descriptionHash同理。还有一个是tx.wait()的默认超时不同链的出块时间差异很大开发阶段如果使用的是测试网建议把tx.wait()换成tx.wait(2)也就是等两个区块确认可以有效避免交易被回滚后再去验真返回 false 的尴尬。3.3 验真页面的反向计算与比对逻辑验真逻辑与存证逻辑恰好相反存证是“我有一份文件计算哈希并上链”验真是“我有一份被质疑的文件重新计算哈希去链上查这条哈希是否存在”。验真函数通常设计成一个页面用户可以拖拽文件、点击按钮、查看链上结果。async function verifyEvidence(file) { // 重新计算被质疑文件的哈希 const evidenceHash await computeFileHash(file); // 连接一个只读节点不需要用户签名 const provider new ethers.JsonRpcProvider(https://your-rpc-endpoint); const contract new ethers.Contract(contractAddress, abi, provider); // 调用合约的查询方法view 类型不会产生 gas 费用 const [exists, timestamp, evidenceType, submitter] await contract.verifyEvidence( ethers.hexlify(ethers.getBytes(0x evidenceHash)), ); if (!exists) { return { valid: false, message: 链上不存在与该文件匹配的存证记录 }; } return { valid: true, timestamp: new Date(timestamp * 1000).toLocaleString(), evidenceType, submitter, }; }验真时不需要钱包签名因为verifyEvidence是view类型方法。这里有一个新手常搞混的点他们会在验真页面也接入 MetaMask导致用户验真时要弹一次签名确认。这是典型的体验坑。连接钱包只在提交证据时需要验真用只读 RPC 节点即可。view方法不消耗用户 gas但每次验真都要访问链上数据。如果单个证据要被高频核查可以在前端加一层结果缓存同一个evidenceHash在 10 分钟内只查一次链其余走缓存。不要为了追求实时性每次都打节点链上数据本身是确定性的不会突然变化。4. 前端源码层的参数配置与 4 个必踩的坑拿到一套存证前端源码后第一件事不是去看页面效果而是把目录结构、内部参数和连接配置梳理清楚。很多人因为跳过这步在联调时才遇到“哈希对不上”“交易一直查不到”“验真永远失败”这些疑难杂症。4.1 前端源码的目录划分与职责边界一套合格的区块链电子证据存证系统前端源码目录应该能一眼看出哪些是纯 UI、哪些是链上交互、哪些是工具函数。src/ components/ # 页面组件证据列表、上传区、验真区 sdk/ # 区块链交互封装唯一允许 import ethers 的层 hash.js # 文件哈希计算 evidence.js # 存证与验真方法封装 provider.js # 节点连接与钱包连接配置 store/ # 前端状态管理已提交证据列表、验真记录 utils/ # 时间格式化、描述哈希计算等通用函数 config/ chain.js # 链 ID、RPC 地址、合约地址统一配置这个划分的核心原则是隔离。UI 组件不能直接引用ethers所有链上操作必须走sdk/层所有链相关的地址、节点 URL 必须集中在config/chain.js。前端源码如果存在“多个页面各自连接节点、各自写死合约地址”的情况基本可以判断代码质量不高后续维护会非常痛。sdk/provider.js里我一般会同时维护两个 provider写操作用钱包 provider读操作用 RPC provider。这样验真流程不会要求用户登录而提交流程又能拿到签名权限。如果源码只在组件里创建了一个 provider建议第一时间拆开。4.2 三个必调参数链 ID、RPC 地址与合约地址任何前端源码在跑起来之前都要正确设置三个参数。这三个参数不匹配整个系统可以做到“启动成功但业务全废”。参数位置作用排查要点链 IDconfig/chain.js识别你接入的是哪条链测试网填错会导到钱包拒绝签名或交易找不到RPC 地址config/chain.js读链上数据的节点入口使用公共 RPC 时会限流正式环境需自建或付费合约地址config/chain.js定位存证合约实例换链必须同步换新部署的合约地址链 ID 是最隐蔽的坑。如果你连接的是 Polyjuice、BSC、HashKey 这类 EVM 兼容链部署合约时链 ID 是什么前端就必须填什么。项目方经常提供多个链的部署环境源码里默认链 ID 可能是他们在内网测试链上的一套值你直接拿到公网测试网用MetaMask 会直接报 “Invalid network”。把链 ID 写成一个可配置项不要让它在组件里写死。RPC 地址的坑表现为“时好时坏”。免费公共 RPC 对eth_getLogs这类查询通常限流限流之后页面会出现短暂卡死或验真失败。这个问题不是源码 bug而是基础设施容量问题。正式系统一定要配置自己的节点地址并且在前端加请求超时与重试机制。我见过不少团队花了大量精力排查“玄学问题”最后发现只是免费 RPC 扛不住并发。合约地址的坑最容易发现但最让人头大页面能打开也能看到提交按钮但调用合约方法时一直报错 “contract call reverted”。这时候先核对地址再核对 ABI 版本。如果源码里的storeEvidence方法签名与链上合约不一致即使地址正确也会 revert。建议前端在启动时无论如何都调用一次只读方法比如verifyEvidence查一条空哈希用返回值确认合约地址正确这个探活动作能省很多排查时间。4.3 避坑排障当前端存证系统遇到的 4 个常见故障以下是我在前端存证源码联调中反复遇到、且每次都能通过固定步骤解决的四个问题。现象一同一文件前后两次计算的哈希不一致。原因多数是文件被二次加工了。文件上传时如果走了“压缩”或“转存”逻辑内存中的二进制已经变化哈希自然不同。另一个常见原因是补零丢失就是我前面说的padStart(2, 0)被漏掉。解决在两个地方同时打印哈希——用户选择的文件对象直接算一次确认前再算一次。如果两次结果不同优先检查文件对象源头如果每次都是同一个结果但和链上不一致则重点检查补零逻辑和 bytes32 转换。现象二提交交易后链上一直查不到记录。原因通常是交易未确认或者你查的链和提交的链不是同一条。前端拿到的receipt.hash只是交易摘要如果前端链 ID 配错了钱包会把交易发送到另一条链。解决用receipt.blockNumber去区块浏览器上核对同时在代码里打印chainId字符串确认搭建连接的目标链。不要凭记忆核对前端 RPC 可配置后经常有人把mainnet和testnet混着填。现象三gas 设置太小交易长时间 pending前端一直等待。原因ethers.js默认会估算 gas但链上拥堵时估算结果往往太低。公共链和联盟链的 gas 机制差别很大。解决提交函数里显式传入 gas 参数比如gasLimit: 120000。不要把这个值写成无限大而是看合约复杂度估算后加 20% 余量。联盟链通常不需要调这笔开销但公链上这是必经步骤。我在前端源码里会加一个开关当链 ID 判断为公链时默认追加gasLimit。现象四前端强制刷新后验真结果变为旧数据。原因链路缓存导致页面拿了旧的合约调用结果而不是真正访问了链上。代码更新后如果仍然显示旧结果多半是浏览器缓存了 JS 文件而这个 JS 又被 CDN 或服务端加了长缓存头。解决在构建配置里给 JS 文件名带哈希值。这对应前端圈常说的“通过版本号的变更让前端强制刷新页面”这一实践。开发阶段可以手动加?t时间戳作临时绕过但生产环境一定要用文件名哈希方案而不是把缓存时间设为 0否则页面每次打开都要重新下载代码体验反而更差。5. 原件不落链前端如何做隐私保护和证据可溯区块链透明性是一把双刃剑。对存证系统来说链上数据所有节点都能读取。如果把合同原件、病历、聊天记录直接上链等于把隐私数据广播给了全网。前端源码需要在“可验证”和“隐私”之间划一条清晰的边界。5.1 上链与不上链的数据边界我一般把证据数据分成三类。第一类是必须上链的文件哈希、时间戳、提交人地址这是证据校验的锚点。第二类是只能上“哈希”的业务描述、案件编号、操作日志用哈希先上链之后要追责时再对明文这种设计叫“承诺-揭示”模式。第三类是绝不能上链的文件原件、大量敏感元数据、用户身份信息。前端的职责是在提交前做分类。很多源码的错误在于把前端收集的原始字段一股脑写入证据结构体导致业务描述明文暴露在链上。正确做法是业务描述在本地加密后存到后端或对象存储只把描述文本的 SHA-256 上链。这一点的价值在仲裁场景中会体现得非常明显原始日志可以在授权后单独解送而不是一开始就被所有人围观。5.2 私有文件存储加链上存 CID 与 SHA-256 的做法对于一些需要保存原件、又不想完全公开的场景常见方案是“对象存储 链上指纹”。原件放在私有桶或加密网关里前端只把存储地址的可定位标识例如 IPFS CID和 SHA-256 一起上链。这样即使存储服务商被要求删除文件链上依然保留“这个 CID 曾经在何时被提交存证”的凭证。前端源码实现时需要注意一个顺序问题应当先算哈希、再存文件、最后上链。原因是文件内容一旦确定哈希就确定如果先上传到存储再取回文件算哈希中间任何一个字节被存储服务商改动漏洞就产生了。以下代码是标准的“先指纹后上传”逻辑。async function storeEvidenceWithPrivateFile(file, privateStorageClient) { // 第一步本地计算原始文件的 SHA-256这一步不依赖任何服务 const evidenceHash await computeFileHash(file); // 第二步上传文件到私有存储桶拿到一个可寻址标识 const cid await privateStorageClient.add(file); // 第三步把 CID 和 SHA-256 打包写入上链结构 const description JSON.stringify({ cid: cid.toString() }); const encoder new TextEncoder(); const descDigest await crypto.subtle.digest(SHA-256, encoder.encode(description)); const descriptionHash ethers.hexlify(descDigest); // 存入合约时哈希与描述哈希同时记录验证时可用 CID 反向定位原件 await storeEvidence(evidenceHash, document, descriptionHash); }这段代码的关键在于第二步和第三步之间没有回读文件。privateStorageClient.add上传完成后直接使用返回的 CID不需要重新下载文件来校验。如果你在这个位置回读了一次文件等于多引入一次传输不可控因素违背了前面前端本地计算哈希的初衷。要注意cid.toString()的格式。不同存储客户端的 CID 版本可能不同旧版默认返回Qm...新版本可能是bafy...。前端测试时第一次成功、第二次失败往往就是 CID 版本变化导致描述哈希不稳定。处理方式是把 CID 转换为统一版本后再计算描述哈希并固定这一策略不要两种版本混用。5.3 多节点验证一致性的边界条件验真环节最容易让人产生疑虑“我自己搭的节点验真当然是对的换一个独立节点还能对上吗”这是对存证系统最合理的怀疑。前端源码要应对这个场景通常做法是支持配置多个 RPC 地址对同一条证据进行双节点校核。实现逻辑很简单用两个不同的 RPC 调用verifyEvidence返回结果对比一致才认定通过。要注意的是两个节点返回的timestamp可能因为区块同步延迟存在细微差异比对时不应精确到秒而是允许一个区块时间窗口常见是 3 秒内的浮动。前端源码如果直接做timestamp1 timestamp2的严格比较在部分链上会造成误报。双节点校核应该放在「证据提交确认」环节而不是放在验真环节。提交时做双节点确认可以尽早暴露节点数据不一致的问题验真时再做双节点确认用户等待时间会翻倍体验变差。我把这个策略归结为同一哈希、双节点、时间窗口浮动缺一不可。6. 验收级的存证演示离线模式与验证报告导出的一个实用技巧存证系统交付后业务负责人最关心的场景是“现场演示时能不能快速给出来”。演示环境经常没有稳定的外部网络或者节点服务不稳定这种时候直接连外部 RPC 很容易出错。一个实用的做法是准备一个本地模拟节点把整套存证、验真流程在离线状态下跑通。离线演示的核心是准备一个“与目标链行为一致”的本地节点。常见做法是用anvil启动一个开发链部署一份与生产完全一致的合约然后把前端config/chain.js里的三个参数切到本地地址。前端代码不需要任何改动因为ethers.js只感知 RPC 协议不感知你连接的是本地还是远程节点。这个方案能在演示时完全避开网络抖动也让演示过程百分之百可控。anvil --chain-id 31337 --port 8545启动后本地 RPC 地址就是http://localhost:8545MetaMask 里添加一个自定义网络链 ID 填31337。接着用合约部署脚本在本地部署存证合约把返回的合约地址替换到前端配置里。前端的storeEvidence和verifyEvidence无需任何改动因为它们的依赖只是三个参数。这里有一个细节要注意本地节点的账号地址与生产链不同submitter地址在演示时会是本地测试账号。为了让演示显得真实配置一个带代币资金的钱包地址用于签名即可。不要为了演示效果去伪造submitter地址那样反而破坏了演示的可信度。演示的另外一个加分项是导出一份验证报告。这对应证据存证系统的一个重要使用场景原件分散在不同人手上需要一份机器可读的验证报告来说明“这个证据在链上确实存在过”。前端源码可以提供一个导出按钮把验真结果和基础证明文件打包。在这个报告里我认为最重要的字段不是文件本身而是“链上查询时的区块高度”与“交易哈希”。当报告被再次检核时直接拿这两个字段去区块链浏览器上核对比再次调用合约方法更令人信服。报告的导出格式建议使用 JSON结构如下包含文件哈希、存证时间、提交人地址、交易哈希、查询区块高度。有经验的法官或仲裁员会拿交易哈希去区块浏览器里独立查看而不是只看你的报告页面。前端源码在这一步要做的是把字段输出完整、标准化宁可多一个区块号不要少一个交易哈希。我在做存证前端时养成了一个习惯任何页面在发布前都要先过一遍“断网场景”。因为存证系统本质是一个“事后核查”的工具集成方常常在弱网环境下面临验收提前把离线演示跑通等于给了现场一条后悔药。整个过程走过的弯路也很多从padStart补零这种几行代码的小坑到 RPC 选型这种容易让人误判为“玄学”的架构问题总结下来其实都符合一个规律证据链前端里没有真正玄学只要把文件来源、哈希计算、链配置这三件事理清楚就可以从「演示能跑」走到「演示能验收」。希望这篇笔记能帮到你。本文还有配套的精品资源点击获取