企业官网建设流程全解析

说实话，第一次看到“区块链文件转储系统”这个题目时，我第一反应是：这又是个把新技术硬贴到老需求上的作业题？文件转储不就是把文件从A盘拷到B盘，或者从服务器搬到对象存储吗，跟区块链能扯上什么关系？

但真正把需求拆开之后，我才意识到这个题目的巧妙之处。它要解决的根本不是“文件怎么搬”，而是“搬完之后怎么证明文件没被篡改、转储记录不可抵赖”。传统方案里，文件拷完了顶多留个日志，日志存在本地数据库里，管理员想改就能改，出了问题说不清楚。而区块链恰好提供了一套“谁在什么时间存了什么文件、哈希值是多少、后续有没有被改动”的可信审计链路。

这篇文章我就完整拆解这个项目的设计与实现思路。整体技术栈是Java、JS、Python三端协作，我会讲清楚三端各自负责什么、为什么这么分工、核心的区块结构和文件快照算法怎么设计，以及我在实际运行和调试过程中踩过的几个比较隐蔽的坑。无论是想把它做成课程设计、毕业设计，还是作为区块链应用的练手项目，这篇文章都能给你一条可以直接落地的路径。

1. 先把“文件转储”和“区块链”的关系想明白

1.1 链上存哈希，链下存本体

很多初学者容易陷入一个误区：以为区块链文件转储系统就是把文件内容直接写进区块链里。真这么干的话，一个几GB的视频文件会让节点同步直接崩溃，而且绝大多数区块链平台对单笔交易的数据体积有严格限制，存大文件既不现实也不经济。

正确且常规的做法是“链上存证、链下存储”。文件本体仍然存放在传统文件系统、分布式存储集群或者IPFS这类内容寻址网络中，而区块链上只记录文件的核心指纹信息，也就是哈希值。系统每隔一段时间对指定目录做一次快照，把目录下每个文件的相对路径、文件大小、修改时间、SHA-256哈希值生成一份清单，再把这份清单的摘要写入区块链交易中。

这么设计的好处非常明显。文件内容有没有被篡改，只需要重新计算一次哈希并与链上记录比对；转储记录有没有被偷偷删除或回滚，因为有区块链的追加式结构和哈希链锁定，几乎不可能做到不留痕迹。区块之间通过前哈希字段串联，改任何一笔历史交易都会导致后续所有区块哈希失效，全网节点立刻能发现异常。

1.2 区块与交易的数据结构设计

在这个项目里，区块链本身不需要做得很复杂，也不需要真正实现挖矿和代币。我们把它设计成一个“可信存证链”，每个区块里打包若干条文件转储记录。

区块头可以按下面的字段来设计：

交易记录是转储动作的最小单元，一条完整的交易包含文件相对路径、操作类型、文件哈希、文件大小、操作时间。操作类型我建议至少预留三种：ADD表示新增文件、UPDATE表示文件内容发生变化、DELETE表示文件已被移除。这样后续做增量转储时，区块链上能还原出文件在整个生命周期里的完整变化轨迹。

区块Hash的计算方式看起来简单，但有一个细节必须注意：字段拼接顺序一旦定下来就不能随意改动，否则不同语言算出来的结果对不上。我在这个项目里固定使用“blockHeight + prevHash + merkleRoot + timestamp + nonce”的顺序拼接字符串然后做SHA-256。Java和Python侧都严格按这个顺序生成，才能保证校验结果一致。

1.3 为什么需要三端协作

单看链表结构，似乎用任何一种语言都能独立完成整个系统。但实际做起来会发现，文件扫描与哈希计算、区块链核心逻辑、用户交互展示这三个环节对语言的擅长点要求完全不同。

Python在处理文件和文本方面极其高效，几行代码就能递归遍历目录并计算哈希，非常适合做数据预处理管道。Java拥有成熟的后端生态，Spring Boot可以快速搭建REST API，同时Java的强类型特性让区块数据结构的定义更严谨，适合作为核心节点程序。JS则天然适合做浏览器端展示面板，可以调用Java后端接口，把区块信息、文件校验状态可视化地展示给用户，这也是绝大多数区块链浏览器的交互模式。

三端分工明确之后，整个系统的数据流就清晰了：Python扫描并生成文件清单，Java接收清单并打包成区块上链，JS拉取链上数据展示并触发校验。任何一个环节都可以单独替换或升级，不互相绑架。

2. 三端各自负责什么：分工与通信机制

2.1 Python端：目录快照与哈希计算的流水线

Python端在系统里的角色是“数据准备层”。它负责把指定目录变成结构化的文件清单JSON，并且计算每个文件的哈希值。这一步决定了后续Java上链的数据质量，所以扫描逻辑不能马虎。

我在实现里用了标准库os和hashlib，没有引入第三方依赖，方便部署。核心逻辑是遍历目录，对每个文件读取内容并计算SHA-256。需要注意大文件不能一次性读入内存，要用分块读取的方式，每块64KB循环更新哈希对象，否则遇到几个GB的文件直接内存溢出。

import os import hashlib import json import time def sha256_file(file_path, block_size=65536): sha = hashlib.sha256() with open(file_path, 'rb') as f: while True: block = f.read(block_size) if not block: break sha.update(block) return sha.hexdigest() def scan_directory(root_path): manifest = { "scanTime": int(time.time() * 1000), "rootPath": root_path, "files": [] } for current_dir, sub_dirs, file_names in os.walk(root_path): for file_name in file_names: full_path = os.path.join(current_dir, file_name) relative_path = os.path.relpath(full_path, root_path) stat_info = os.stat(full_path) file_hash = sha256_file(full_path) manifest["files"].append({ "relPath": relative_path, "size": stat_info.st_size, "mtime": stat_info.st_mtime, "hash": file_hash, "opType": "ADD" }) return manifest if __name__ == "__main__": root = "/data/to_be_archived" manifest = scan_directory(root) with open("/tmp/manifest.json", "w", encoding="utf-8") as fp: json.dump(manifest, fp, ensure_ascii=False, indent=2)

这份清单生成之后，Python就把接力棒交给Java。实际部署中，可以通过HTTP POST把JSON推送给Java节点的/api/blockchain/append接口，也可以保存到约定好的消息队列里。我建议直接走HTTP，逻辑简单且便于演示。

2.2 Java端：区块生成、交易打包与校验核心

Java端是整个系统的心脏。它要维护三条关键数据结构：交易池、区块链列表和文件台账索引。交易池是待上链的转储记录缓存，文件台账索引则是文件相对路径到最新区块高度的映射，用于快速回答“这个文件最后一次登记是在哪个区块”。

区块生成的核心逻辑是不断从交易池取出记录，做Merkle哈希，然后组装区块体。我在Java里定义了一个Block类，关键字段和之前表格一致。生成新区块时，必须先把交易池里的记录按时间戳稳定排序，再统一计算哈希树，否则交易顺序不同会导致同一批数据算出不同的Merkle根。

Merkle根的计算不复杂，就是把交易记录先各自做一次SHA-256得到叶子节点哈希，然后两两拼接再做哈希，直到收敛为一个根哈希。如果交易数量是奇数，就把最后一个哈希复制一份跟自己拼接，始终保持两两配对。

public String calculateMerkleRoot(List<Transaction> txs) { List<String> layer = new ArrayList<>(); for (Transaction tx : txs) { layer.add(sha256(tx.getRawContent())); } while (layer.size() > 1) { List<String> nextLayer = new ArrayList<>(); if (layer.size() % 2 == 1) { layer.add(layer.get(layer.size() - 1)); } for (int i = 0; i < layer.size(); i += 2) { String combined = layer.get(i) + layer.get(i + 1); nextLayer.add(sha256(combined)); } layer = nextLayer; } return layer.get(0); }

Java对外提供几个核心REST接口：

这里有一个值得注意的设计点：Java端要做轻量校验，收到Python的清单后，不是直接打包上链，而是先检查每一条记录的JSON格式是否合法、文件哈希是否确实是64位十六进制字符串、大小是否为非负数。玩过区块链的人都知道，脏数据一旦上链就永远抹不掉，所以入链前的输入校验必须严格。

2.3 JS端：数据可视化与交互校验

JS端在这个项目里不是重头戏，但它是整个系统“看得见”的部分。我用原生JS加一个简单的HTML页面，不引入Vue或React，主要数据展示通过fetch调用Java的REST接口实现。

页面上需要展示四个核心区域：最新区块信息、最近转储记录列表、文件校验入口、链状态概览。区块信息包括高度、时间戳、前哈希、Merkle根和当前区块哈希。文件校验入口则是一个输入框加按钮，用户输入文件相对路径后，JS端调用Java的verify接口拿到链上记录的哈希，同时计算本地文件的哈希，两边比对后给出“一致”或“被篡改”的结论。

JS端有一个细节容易踩坑：Java接口返回的哈希是十六进制字符串，但在JavaScript里处理这类长字符串时要注意不能把它当作数值类型。哈希值要保持在字符串类型里比较，不要做任何parseInt操作，否则不仅会丢精度，还会得到完全错误的比对结果。

async function fetchLatestBlock() { const response = await fetch('/api/blockchain/latest'); const block = await response.json(); document.getElementById('block-height').innerText = block.blockHeight; document.getElementById('block-hash').innerText = block.blockHash; document.getElementById('prev-hash').innerText = block.prevHash; document.getElementById('merkle-root').innerText = block.merkleRoot; } async function verifyFile() { const filePath = document.getElementById('file-path-input').value.trim(); if (!filePath) return; const response = await fetch(`/api/blockchain/verify/${encodeURIComponent(filePath)}`); const result = await response.json(); renderVerifyResult(result); }

在演示系统中，JS页面可以直接用VSCode Live Server打开，Java后端跑在8080端口，前后端通过代理或跨域配置联调。如果不想配置CORS，最简单的办法是在Java侧加一个@CrossOrigin注解，或者用Spring Boot的全局跨域配置把本地前端开发服务器的地址放行。

3. 文件快照与增量转储：别把每次全量扫描结果都上链

3.1 全量快照的存储浪费问题

如果每次转储都把目录下所有文件的哈希重新上链一遍，前期文件少的时候没问题，但文件多了之后交易量会爆炸。假设目录里有1万个文件，做10次转储，区块链上就有10万条记录，其中绝大部分是重复数据。这不环保，也不必要。

更合理的做法是设计增量快照机制。第一次扫描时所有文件标记为ADD；后续扫描时逐个文件比对当前哈希和上次记录的哈希，没变化的不产生交易记录，有变化的标记为UPDATE，新出现的标记为ADD，文件消失的标记为DELETE。这样每次上链的交易数量只跟“变化文件数”有关，与目录下文件总量解耦。

Python端的扫描函数需要升级一下，增加一个“上一次清单”参数。每次生成新清单前，先读取上一次的manifest.json文件建立哈希映射，然后逐文件比对。

def build_incremental_manifest(root_path, prev_manifest_path): prev_map = {} if os.path.exists(prev_manifest_path): with open(prev_manifest_path, "r", encoding="utf-8") as fp: prev_data = json.load(fp) for item in prev_data["files"]: prev_map[item["relPath"]] = item["hash"] new_manifest = { "scanTime": int(time.time() * 1000), "rootPath": root_path, "files": [] } current_map = {} for current_dir, sub_dirs, file_names in os.walk(root_path): for file_name in file_names: full_path = os.path.join(current_dir, file_name) relative_path = os.path.relpath(full_path, root_path) stat_info = os.stat(full_path) file_hash = sha256_file(full_path) current_map[relative_path] = file_hash if relative_path not in prev_map: new_manifest["files"].append({ "relPath": relative_path, "size": stat_info.st_size, "mtime": stat_info.st_mtime, "hash": file_hash, "opType": "ADD" }) elif prev_map[relative_path] != file_hash: new_manifest["files"].append({ "relPath": relative_path, "size": stat_info.st_size, "mtime": stat_info.st_mtime, "hash": file_hash, "opType": "UPDATE" }) for rel_path in prev_map: if rel_path not in current_map: new_manifest["files"].append({ "relPath": rel_path, "size": 0, "mtime": 0, "hash": "", "opType": "DELETE" }) return new_manifest

增量清单生成后，照旧推送给Java端。Java端解析时会根据opType字段走不同的处理逻辑：ADD和UPDATE直接作为转储记录写入交易池，DELETE则生成一条置空哈希的删除记录。区块链上会清晰地保留这个文件“什么时候新增、什么时候修改过、什么时候被删除”的完整生命周期。

3.2 Java端如何维护文件台账

为了支持增量更新，Java端必须持久化维护一份“文件台账索引”。这个索引本质上是一个Map，键是文件相对路径，值是包含最新区块高度和最新哈希的封装对象。

每次新区块生成后，Java会遍历这个区块里的所有交易记录，更新台账索引。需要注意的处理顺序是：先按下发顺序处理ADD和UPDATE，再处理DELETE，避免同一个文件在同一批交易里先删后增时索引状态错乱。

这份台账索引还需要支持重启恢复。最简单的方式是每次区块生成后，把整个台账序列化成本地JSON文件落盘。因为文件数量通常不会太大，这种全量快照的方式完全够用。后续如果文件数量巨大，可以换成嵌入式数据库比如SQLite或者H2，但不建议一开始就在这个项目里引入过重的存储组件。

3.3 文件校验的完整链路

文件校验功能是整个系统最有说服力的演示环节。流程是这样的：用户指定一个本地文件路径，前端把路径发给Java节点，Java节点查询台账索引返回该文件链上最新哈希。同时，前端调用一个由Python启动的本地计算服务来计算目标文件的实时SHA-256，两边结果一致就说明文件没被动过。

这里有一个交互上的坑：Java节点校验的是它自己磁盘上的副本，而不是用户浏览器所在机器上的文件。如果Java节点和文件存储不在同一台机器上，校验就失去了意义。所以部署时，要么让Java节点直接挂载存储磁盘，要么把校验服务部署成独立的Python HTTP服务，由它去读取被校验文件并计算哈希，再把结果返回给JS前端做比对。我在项目里选择了后者，这样三端的分工也更名副其实：Python算哈希，Java查链上记录，JS做比对展示。

校验服务的核心代码就是一个返回文件SHA-256的Flask接口：

from flask import Flask, request, jsonify import hashlib app = Flask(__name__) @app.route("/hash", methods=["POST"]) def calc_hash(): data = request.get_json() file_path = data.get("filePath") sha = hashlib.sha256() try: with open(file_path, "rb") as f: while True: block = f.read(65536) if not block: break sha.update(block) return jsonify({"hash": sha.hexdigest(), "filePath": file_path}) except FileNotFoundError: return jsonify({"error": "file not found"}), 404 if __name__ == "__main__": app.run(port=5001)

4. 多节点一致性：同一批文件被不同节点转储时怎么办

4.1 从单节点到多节点的同步问题

课程设计和毕业设计通常只需要单节点演示。但既然题目叫区块链系统，完全不考虑多节点又会显得不够完整。我建议在架构上预留以太坊那套简化版流程：多个Java节点各自维护一条链，通过P2P广播同步新区块。

最简单的节点通信机制是HTTP长轮询或WebSocket。每个节点不仅对外提供REST接口，还要主动连接其他已知节点，定时拉取对方的最新区块高度。如果发现自己高度落后，就请求对方把缺失的区块按顺序补回来。如果发现自己高度领先，就把自己的最新区块广播出去。

节点启动 -> 加载本地链 -> 连接种子节点 -> 同步区块 -> 进入正常服务状态 正常服务 -> 收到交易 -> 打包区块 -> 本地存储 -> 广播给其他节点 -> 其他节点校验并追加

同步协议里最核心的接口是/api/blockchain/sync?startHeight=100，返回从指定区块高度开始的所有区块。接收方拿到这些区块后，逐个做完整性校验，包括区块Hash是否匹配、前哈希是否衔接、交易记录是否合法。全部校验通过才写入本地链。

4.2 链分叉的简化处理

多节点同时收到不同交易时会出现链分叉。比如节点A和节点B几乎同时收到两笔不同的转储记录，各自生成了高度都是10的新区块，但内容不同。简化版的解决策略就是大多数人熟悉的“最长链原则”：各自把新区块广播出去，节点收到分叉区块时暂时都保留，但只承认累计工作量更大（这里简化为高度更高）的那条链为主链。

处理分叉的代码逻辑需要注意一个细节：切换主链时，之前主链上独有但新主链没有的交易记录不能直接丢弃，应该重新放回交易池，等待下一次被打包。否则这些转储记录会永久丢失，违背了系统的审计初衷。

public void handleFork(List<Block> forkBlocks) { int currentHeight = this.blockchain.size() - 1; if (forkBlocks.size() <= currentHeight) { return; // 新链不更长，忽略 } // 回滚当前链上的交易索引 rollbackLedger(); // 切换新链 this.blockchain = new ArrayList<>(forkBlocks); // 重新建立台账索引 rebuildLedger(); }

在这个项目里，真正的PoW计算和难度调整不是重点，所以不需要引入高强度的哈希碰撞计算。但是写一个轻量级的“区块工作量验证规则”也不难：新区块Hash必须以若干个0开头，难度值可以固定为4个0。这个规则能让同学们直观感受到矿工挖矿的本质：不断改变nonce让区块哈希满足条件。对于展示来说，这个特性的观赏性很强，我可以看到区块Hash确实以0000开头，并理解为什么nonce是最后一个敲定的值。

4.3 交易池的并发排序

Java端如果同时收到多个文件清单推送，交易池里会出现记录顺序不一致的问题。比如目录先推送了manifest_A，后推送了manifest_B，但网络抖动导致Java反而先收到B后收到A。直接把交易按收到的顺序入池再打包，链上记录的时间顺序就会错乱。

解决办法是给每个清单增加一个单调递增的序列号，这个序列号由Python端扫描时生成。Java端收到清单后不直接写入交易池，而是先放进待排序缓冲区，按序列号排序后按序写入交易池。只有序列号连续且递增的清单才有资格被打包进区块。

序列号机制同时能解决一个隐蔽的Bug：Java节点的服务重启后，如果消息队列里还有旧消息，不处理的话会造成历史重复上链。有了序列号，Java端可以记录上一次已处理的序列号，重复消息直接丢弃即可。这个设计在真正上生产系统时同样适用。

5. 实测踩坑记录：三端哈希对不齐、编码混乱和性能陷阱

5.1 Python和Java的SHA-256结果不一致

这是我第一次联调时遇到的第一个问题。Python端计算的哈希和Java端重新计算的哈希竟然不一样，排查了半天，最后发现是文件读取方式不同导致的。Python端默认按文本模式打开文件还是二进制模式，这是一个决定性的差异。

在文本模式下，Windows系统会把\r\n转换成\n，导致读到的字节流和文件实际二进制内容不一致，哈希自然对不上。解决方案是文件中明确使用'rb'二进制模式读取。Java端同理，必须用Files.readAllBytes或者FileInputStream逐块读取，不能使用BufferedReader.readLine这类文本读取方式。这个问题一旦发生，表现是“小的文件哈希偶尔一致，大的文件哈希永远不一致”，非常迷惑。

5.2 中文文件名和中文路径的编码问题

文件目录里一旦出现中文路径，三端协作就会冒出各种编码问题。Python端默认UTF-8，在Windows上可能会遇到GBK编码的文件名。Java端接收JSON时如果没设置字符集编码，默认使用平台编码，Windows下就是GBK。JS端从接口拿JSON倒是没问题，但如果直接用未编码的中文去拼URL，后端接到的路径就是乱码。

我的处理方案分三步。第一步，Python扫描时，所有路径字段统一用相对路径并以UTF-8编码，JSON文件写入时指定ensure_ascii=False，并声明编码UTF-8。第二步，Java端所有HTTP接口的Content-Type显式设置为application/json;charset=UTF-8，Spring Boot的配置文件中设置server.servlet.encoding.force=true。第三步，JS前端调用verify接口时，用encodeURIComponent(filePath)对中文路径进行一次编码，Java后端用@PathVariable接收后再做一次URL解码。三条链路统一之后，中文文件名的校验就再没出过问题。

5.3 大文件哈希计算造成的扫描停顿

单次扫描目录时，如果某个文件有5GB以上，Python端逐块读取需要几秒甚至更长。整个扫描进程是单线程的，意味着扫描期间无法响应其他任务。在演示现场跑数据量大的目录时，“卡住不动”的观感非常差。

我的优化方案是引入生产者消费者模式。Python端扫描线程只负责获取文件路径列表，计算哈希的工作交给线程池并发执行，线程数控制在CPU核心数附近。用concurrent.futures.ThreadPoolExecutor可以几行代码实现并行哈希，扫描总耗时能缩短好几倍。需要注意，哈希计算是CPU密集型任务而不是IO密集型任务，所以线程数并不是越多越好，超过CPU核心数反而会因为上下文切换变慢。

另一个优化点是跳过无变化的文件。增量模式下，如果文件大小和修改时间都与上次一致，就默认哈希没变，直接复用上次记录。这是经验值：文件内容不变时，大小和mtime同时不变的概率非常高。当然严格来说这个逻辑存在理论上的误判可能，但实际文件和目录管理中已经足够可靠。

5.4 JS端字节数组转字符串的哈希精度丢失

前端做本地校验时，我一开始尝试用JS读取文件内容计算哈希，但写到半路发现一个大问题：JavaScript的FileReader.readAsText读取文件时会把二进制数据按文本解码，遇到PDF、压缩包这类非文本文件时，编码转换会改变数据内容，计算出的哈希必然不正确。

正确做法是用FileReader.readAsArrayBuffer拿到二进制缓冲区，再用crypto.subtle.digest计算哈希。Web Crypto API是浏览器内置的标准接口，不需要引入第三方库。但要注意这个接口是异步的，返回的是一个Promise，需要在async函数里await结果。若直接用同步写法，会拿到一个永久pending的Promise对象。

5.5 并发转储时交易顺序错乱导致审计链失真

我在4.3节提到了序列号机制。这是我在压测时发现的问题：我同时向Java节点推送两个目录清单，结果上链后发现两个区块的交易记录混杂，同一个文件的ADD记录出现在UPDATE记录之后，审计路径完全乱了。加序列号之后，Java端强制按序号消费清单，确保先扫描到的目录先上链。如果系统要求更严格，还可以把文件台账索引的更新操作加上锁，避免多线程同时修改Map造成并发异常。

6. 从能跑到能用：项目演示与扩展方向

6.1 演示环境的完整搭建流程

如果急着把这个项目拿出来展示或答辩，我建议准备一台Linux服务器或者本地虚拟机，按下面的顺序初始化环境：

1. 安装JDK 17、Python 3.10以上版本，Node.js 18以上版本。
2. 创建待转储目录，放入不同格式的测试文件，包括txt、jpg、pdf、mp4，最好再放一个中文文件名文件，展示编码处理能力。
3. 启动Java节点，调用genesis接口初始化创世区块。
4. 启动Python扫描程序，生成第一份全量清单并推送给Java。
5. 等待Java打包生成第一个区块，用浏览器打开JS页面，确认区块高度为1。
6. 手动修改一个测试文件的内容，重新运行Python扫描，确认产生了UPDATE交易。
7. 在JS页面执行文件校验，展示“文件已被修改”的红字提示。

这套流程跑下来，区块链的防篡改能力会被完整地展示出来。尤其是最后一步，修改文件后哈希比对失败的瞬间，观众会直观理解到哈希锁定的价值。

建议把每一步的操作结果截图保存。答辩演示最怕现场翻车，提前准备好文字记录和截图，万一现场服务起不来，至少还有完整的证据链证明系统是可运行的。

6.2 回答评委问题的内容储备

关于这个项目，被问到最多的问题通常集中在几个方向上。第一个问题是“区块链在这里解决了什么传统方案解决不了的问题”。回答的核心是：传统文件归档系统的日志存在中心化数据库里，管理员有权限修改日志，无法审计；本方案把转储记录的哈希链广播到多个节点，任何单点篡改都会被其他节点的副本校验发现。

第二个问题是“数据存在哪里”。要明确回答：文件本体不在链上，链上只有哈希和元数据。文件可以存放在分布式文件系统或对象存储中。平时写论文和汇报时，别忘了加上“链上链下协同存储”这个架构术语，这是评委会非常认可的思路。

第三个问题是“共识机制是什么”。这个项目没有实现完整的工作量证明，而是用简化的最长链规则做节点间同步。回答时应当坦诚说明这是教学简化版，并补充说明如果要生产化部署，可以替换为PBFT或者Raft这类更适合联盟链场景的共识算法。

6.3 后续可以扩展的方向

如果还想继续深挖这个项目，有三个扩展方向我认为性价比很高。一是接入IPFS作为文件本体存储层，把Python端计算出的文件哈希和IPFS返回的CID做映射，这样文件在链上的存证和内容寻址存储能形成闭环。二是增加交易签名机制，每一笔转储记录附带操作者身份的公钥签名，区块链不可篡改之外还能做到操作者不可抵赖，这就是真正的数字存证系统了。三是给JS端增加区块列表可视化，加上一个按时间线滚动的区块查看器，观感会专业很多。

我做这个项目最大的体会是：技术难度不在区块链本身，而在于让三种语言顺畅协作、让数据在不同组件之间传递时不失真。文件编码、哈希算法、时间戳排序，这些基本功扎实了，区块链反而只是最后一层包装。

如果你也打算基于这个题目做项目，我建议动手之前先把“哪些内容上链、哪些内容不上链”这个边界想清楚，之后所有设计都会顺畅很多。