简介面向计算机相关专业毕业设计场景这份资源提供了基于Spring Boot与以太坊的项目评审系统完整方案涵盖系统源码、部署文档与项目配套资料可支撑毕业设计、课程设计、实训演示以及项目初期立项等多种用途。包体共收录二百零八个文件压缩后大小约为七百七十一KB其中Java源码承担后端业务逻辑JavaScript脚本与FreeMarker页面模板及CSS样式共同搭建前端展示GIF动画可直观呈现运行效果SQL脚本用于初始化数据库Solidity合约及ABI和BIN文件对应以太坊链上交互从界面操作到智能合约调用均有对应素材适合完整研读与二次开发。当前已有约一百一十人学习下载。据资源说明该项目为高分完整源码答辩得分九十五分且已测试运行适合软件工程、区块链、人工智能等专业在校师生解压可获得可部署的工程结构、智能合约交互实现、部署文档与项目资料内容预览含构建脚本及登录注册页面能够减少环境搭建与界面理解成本若有编程基础可在此基础上扩展评审流程或权限模块是快速上手区块链应用开发的高质量参考。1. 基于SpringBoot和以太坊的评审系统真正的加分项是“哪些地方不上链”区块链毕业设计里最容易翻车的做法是开发者兴奋地把项目材料、专家信息、打分理由全部塞进智能合约结果Gas费高得离谱、界面卡成幻灯片答辩时还被老师问住。基于SpringBoot以太坊做项目评审系统核心卖点从来不是“用区块链替代数据库”而是让评审过程中最容易被质疑的环节——项目提交时间、专家评分、状态流转——变成链上交易。交易哈希、区块号、时间戳全部公开可查评审结果改了也赖不掉。这篇文章会按我实际做这类系统的顺序展开先划清链上和链下的边界再写合约、用Web3j把合约变成SpringBoot接口最后给出部署和答辩验证的具体路径。适合正在定题的毕设同学也适合想给老评审系统加一层“存证外挂”的开发者。2. 把评审流程拆成链上与链下先想清楚边界再动手写合约2.1 评审系统为什么选择“链上存证”而不是“链上跑完整业务”项目评审业务的本质是发起方提交项目→组织方分配专家→专家打分→汇总结果。传统SpringBoot系统用一张score表和一个状态字段就能做完整套流程但有个没法回避的问题数据库管理员可以改分项目方可以质疑某个专家是否真的在那个时间点提交了评分。而区块链能解决的不是“自动化评审”是“证据固化”——把每一次关键操作变成一笔交易交易里带上调用者地址和时间戳任何人可以通过区块浏览器或者Ganache的交易列表看到它。所以我在给A同学做这个毕设题目时第一件事不是打开IDE写代码而是画一张数据边界表。需要上链的是项目Id、提交者地址、提交时间、专家地址列表、每个专家的评分、项目最终状态。不需要上链的是项目文档原文、专家姓名、评审意见文本、通知记录。这些留在MySQL里通过projectId与链上数据关联。这样设计的好处是合约保持轻量业务功能仍然用SpringBoot的成熟能力实现区块链只负责“记账”。2.2 为什么选以太坊而不是Fabric或自研链毕业设计需要“看得见的交易”我见过不少同学一开始想用Fabric理由是“联盟链效率高”。但Fabric的部署依赖Docker镜像、排序节点、组织证书一套环境折腾两个星期是常态而且Fabric没有一个像Ganache这样双击就能跑的图形化链。以太坊的优势在于开发体验Ganache启动后自带十个账户、每个账户100个测试币还能在界面里直接看到每笔交易流入哪个区块这对答辩演示非常友好。另一个更实际的原因是资源网上能找到的中文资料、博客、错误修复帖绝大多数都是以太坊Web3j方向遇到问题搜索成本低。安全方面要提醒一句测试网络的私钥只用于本地演示千万不要把它当成正式环境使用。整个开发期我只需要一条本地私链配置很简单网络ID用5777端口7545Gas上限默认就行。这个网络配置会让后续所有合约交互代码复用同一套参数。2.3 合约数据模型状态枚举、项目结构、评分记录的映射关系写合约之前先把数据结构想清楚。我用的核心模型是这样的数据对象所在位置关键字段说明评审项目合约projectId、title、state、scoreSum、scoreCount状态和分数汇总在链上评审专家合约address、projectId、hasVoted专家地址作为唯一身份原始材料MySQLprojectId、fileUrl、description只存业务信息不上链链上索引MySQLprojectId、txHash、blockNumber关联链上和链下合约里用枚举表示评审状态状态变迁是单向的待评审(0)→评审中(1)→已结束(2)。这个状态机的好处是杜绝了“评审结束后重新打分”的操作——合约会检查当前状态只有处于评审中时才能提交评分。每次打分事件里记录评委地址和分数最终汇总交给合约计算平均分避免有人篡改MySQL里的score字段。因为评审专家被限制为只有管理员添加进白名单的地址这个合约不需要实现复杂的权限判断一个onlyOwner修饰符就可以覆盖大多数流转场景。3. SpringBootWeb3j落地从Ganache到REST接口一条链路走通3.1 初始化工程依赖只要三组版本别追新创建SpringBoot项目时pom.xml里加入Web3j、Spring Web和MySQL驱动就够了。版本搭配上我用的是SpringBoot 2.7.x配合Web3j 4.8.x这个组合兼容Java 8和11网上踩坑资料也最全。不要一上来就追Web3j 4.9以上它对Java 17和SpringBoot 3做了调整反而容易引入不必要的报错。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.12/version /parent properties java.version1.8/java.version web3j.version4.8.8/web3j.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.web3j/groupId artifactIdcore/artifactId version${web3j.version}/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency /dependenciesWeb3j的core依赖会带入okhttp作为HTTP客户端它负责与Ganache的7545端口通信。SpringBoot的Parent管理了大部分依赖版本但Web3j需要单独声明版本否则Maven会给你拉一个非常旧的版本旧版本的ABI解码方式和现在写的Solidity 0.8.x合约不兼容这是第一个容易埋雷的地方。3.2 编写ReviewSystem.sol只留四个函数合约我只实现了四个核心函数提交项目、分配专家、提交评分、查询项目。项目登记做成管理员代提交的方式因为毕设场景里往往是管理员统一录入项目信息而不是让每个学生在链上自己注册钱包这样也减少了前端对接的复杂度。// SPDX-License-Identifier: MIT pragma solidity ^0.8.7; contract ReviewSystem { enum ReviewState { Pending, Reviewing, Closed } struct Project { string title; uint256 submitTime; ReviewState state; uint256 scoreSum; uint256 scoreCount; } address public owner; mapping(uint256 Project) public projects; mapping(uint256 mapping(address bool)) public hasVoted; mapping(uint256 address[]) private reviewers; event ProjectSubmitted(uint256 projectId, string title, uint256 submitTime); event ReviewerAssigned(uint256 projectId, address reviewer); event ScoreSubmitted(uint256 projectId, address reviewer, uint256 score); modifier onlyOwner() { require(msg.sender owner, not owner); _; } constructor() { owner msg.sender; } function submitProject(uint256 projectId, string calldata title) external onlyOwner { require(projects[projectId].submitTime 0, existing project); projects[projectId] Project({ title: title, submitTime: block.timestamp, state: ReviewState.Pending, scoreSum: 0, scoreCount: 0 }); emit ProjectSubmitted(projectId, title, block.timestamp); } function assignReviewer(uint256 projectId, address reviewer) external onlyOwner { Project storage p projects[projectId]; require(p.state ReviewState.Pending, wrong state); require(reviewer ! address(0), zero address); reviewers[projectId].push(reviewer); p.state ReviewState.Reviewing; emit ReviewerAssigned(projectId, reviewer); } function submitScore(uint256 projectId, uint256 score) external { require(score 0 score 100, invalid score); Project storage p projects[projectId]; require(p.state ReviewState.Reviewing, not reviewing); require(!hasVoted[projectId][msg.sender], already voted); hasVoted[projectId][msg.sender] true; p.scoreSum score; p.scoreCount 1; emit ScoreSubmitted(projectId, msg.sender, score); } function getProject(uint256 projectId) external view returns (string memory title, uint256 submitTime, uint256 state, uint256 avgScore, uint256 scoreCount) { Project storage p projects[projectId]; uint256 avg 0; if (p.scoreCount 0) { avg p.scoreSum / p.scoreCount; } return (p.title, p.submitTime, uint256(p.state), avg, p.scoreCount); } }合约里有个值得注意的代码习惯状态检查放在业务逻辑之前所有可能失败的调用先require再改状态这样能避免“校验失败但状态被污染”的中间态。参数方面score限制在0到100之间平均分用整数除法计算答辩时可以说清楚“链上只存整数分数统计精度由链下处理”不必为了浮点数把合约做复杂。每个函数都抛出对应的事件事件参数里的projectId和reviewer是后续做索引查询的关键。3.3 编译、生成Java包装类两条命令拉通写好的sol文件需要编译成ABI和二进制。我用的是Solidity编译器的命令行版本# 安装编译器macOS为例具体以你的环境为准 npm install -g solc # 编译输出ABI和bin solc --optimize --bin --abi ReviewSystem.sol -o build/contracts编译成功后build/contracts目录下会有ReviewSystem.abi和ReviewSystem.bin两个文件。接下来用Web3j的命令行工具生成Java包装类这一步会把合约的函数、事件、结构体映射成Java类型。web3j generate solidity -b build/contracts/ReviewSystem.bin \ -a build/contracts/ReviewSystem.abi \ -o src/main/java \ -p com.demo.blockchain.contract参数里-o是输出目录-p是包名。常见的错误是路径分隔符在Windows下用了反斜杠建议在项目根目录执行并让build/contracts保持相对路径。生成后会出现一个ReviewSystem.java里面包含部署方法、每个合约函数的Java封装还有事件类。Web3j对Solidity struct的返回值处理比较特殊getProject会变成一个包含多个字段的Java对象列表下标依次对应返回值顺序建议在服务层把它封装成DTO别直接把数组暴露给前端。3.4 合约部署工具类把地址、网络ID、管理员私钥做成可配置项部署合约最稳妥的方式不是手动操作而是写一个CommandLineRunner启动任务在SpringBoot启动时读取配置并自动部署。这样每次Ganache重置后重新启动项目就能自动部署新合约并打印地址。Component public class ContractDeployRunner implements CommandLineRunner { Value(${blockchain.ethereum.rpc-url}) private String rpcUrl; Value(${blockchain.ethereum.private-key}) private String privateKey; Override public void run(String... args) throws Exception { Web3j web3j Web3j.build(new HttpService(rpcUrl)); Credentials credentials Credentials.create(privateKey); ContractGasProvider gasProvider new StaticGasProvider( BigInteger.valueOf(3000000L), BigInteger.valueOf(20000000000L) ); ReviewSystem contract ReviewSystem.deploy( web3j, credentials, gasProvider).send(); System.out.println(contract address: contract.getContractAddress()); } }静态Gas提供者的两个参数分别是Gas上限和Gas价格。Ganache默认Gas价格是20 Gwei也就是20000000000这是本地网络的默认值写进配置即可。部署输出的地址必须记录到application.yml里后面所有业务接口都依赖这个地址。这里我建议把地址打印和保存做成一步部署成功后自动写入配置文件而不是靠手工复制。手工复制是必然翻车的环节后文避坑章会专门展开。3.5 业务服务层把合约调用变成REST接口处理好链下索引服务层的核心是把合约操作包成ReviewContractService对外提供submitProject、assignReviewer、submitScore、getScoreSummary四个方法。以提交评分为例Service public class ReviewContractService { private final Web3j web3j; private final ReviewSystem contract; private final String adminPrivateKey; public ReviewContractService( Value(${blockchain.ethereum.rpc-url}) String rpcUrl, Value(${blockchain.ethereum.contract-address}) String contractAddress, Value(${blockchain.ethereum.private-key}) String adminPrivateKey) { this.web3j Web3j.build(new HttpService(rpcUrl)); this.contract ReviewSystem.load( contractAddress, web3j, Credentials.create(adminPrivateKey), new StaticGasProvider( BigInteger.valueOf(3000000L), BigInteger.valueOf(20000000000L))); this.adminPrivateKey adminPrivateKey; } public TransactionReceipt submitScore(Long projectId, Integer score) { try { TransactionReceipt receipt contract .submitScore(BigInteger.valueOf(projectId), BigInteger.valueOf(score)) .send(); if (!receipt.isStatusOK()) { throw new RuntimeException(chain transaction failed); } return receipt; } catch (Exception e) { throw new RuntimeException(submitScore on chain error, e); } } }加载合约时我用的ReviewSystem.load它和部署的区别在于不会重新发布合约只是创建本地代理对象每次调用都会构造一个交易发到Ganache。TransactionReceipt里的isStatusOK()用来判断交易是否被链上接受但这里有个容易误判的点send()本身可能因为Gas不足直接抛异常这时候要看异常类型是TransactionException还是RuntimeException前者通常是链上执行回滚后者才是网络或编码问题。服务层拿到回执后要同步把txHash和blockNumber存进MySQL的chain_record表这样评审记录既能在业务页面上展示也能随时回溯到链上验证。4. 最常见的5个坑现象、原因、解决4.1 致命问题合约地址没更新所有接口静默失败一名开发者在演示前重新部署了合约Ganache弹出了新地址但application.yml里的contract-address还是旧值。启动项目后所有接口都返回“transaction failed”而且日志里看不到合约级别的错误因为load一个不存在的地址在Web3j里不算异常交易发送后Ganache会因为合约地址无代码而执行回滚。解决方法是把部署和配置更新做成一个动作。我的做法是写一个脚本先启动Ganache再运行一个仅部署用的测试类部署成功后把地址直接写回application.yml最后才启动SpringBoot主类。三个步骤固定顺序谁也不能跳过。4.2 中文乱码合约返回值在页面里变成问号Solidity的string本质是UTF-8编码的动态字节数组Web3j解析后会交给Java的String对象本身不会乱码。真正导致乱码的是SpringBoot默认的HTTP响应编码和数据库连接串没指定characterEncodingutf-8。现象是合约查出来的标题正常但从MySQL取出来的材料描述乱码两者混在一起就显得“区块链有问题”。原因在链路的不同节点Web3j返回的String已经是正确的Java Unicode字符串问题出在SpringBoot的server.servlet.encoding配置和JDBC URL参数。解决方法是三处同时设置application.yml里配置UTF-8编码JDBC连接串加上useUnicodetruecharacterEncodingutf8前端页面通过meta charsetutf-8声明编码。这样排查有个顺序先确认合约查询接口返回的JSON是否正常再检查后续环节不要在合约里做十六进制编码的过度设计。4.3 nonce太低重启Ganache后连续报错Ganache每次重置链上账户的交易计数会清零。但如果SpringBoot进程没有重启Web3j内部会缓存上一轮会话的nonce再次发送交易时nonce比链上状态高Ganache直接返回“nonce too low”。现象是重启网络后的第一笔交易必失败第二笔偶尔成功之后完全错乱。解决方法是每次发送交易前显式获取最新nonceEthGetTransactionCount count web3j .ethGetTransactionCount(credentials.getAddress(), DefaultBlockParameterName.PENDING) .send(); BigInteger nonce count.getTransactionCount();4.4 Gas预估不足界面显示失败交易却已经上链合约里遍历评委列表或存储较长字符串时实际消耗的Gas可能超过手动设置的300万上限。Web3j抛出的TransactionException会让接口报错但Ganache里已经产生了交易记录状态是0x0导致数据库里没有索引记录链上却有失败的痕迹。解决方式是用ethEstimateGas先预估再乘以安全系数作为GasLimitEthEstimateGas estimate web3j .ethEstimateGas(transaction) .send(); BigInteger gasLimit estimate .getAmountUsed() .multiply(BigInteger.valueOf(2L));这也是为什么我在部署工具类里用StaticGasProvider而不是写死在合约代码里的原因——GasLimit应该可以在配置文件中调整而不是每次改合约都要重新编译。4.5 事件监听错位服务重启后丢历史事件很多资料里用ethSubscribe做实时监听但订阅模式的限制是它只接收订阅之后产生的事件。开发中重启SpringBoot是常态重启前已经上链的评分事件会丢失前端统计列表和合约里的实际数据不一致。最常见的翻车场景是专家投完分后服务重启页面评分记录不显示但合约平均分是包含这一票的。解决方法是改用getPastEvents从指定区块重新扫描ListReviewSystem.ScoreSubmittedEventResponse events contract.getScoreSubmittedEvents( new DefaultBlockParameterNumber(0L), new DefaultBlockParameterName(latest) );首次运行时扫描全部区块之后每次启动记录上次处理的blockNumber从那个区块继续增量扫描。这个方案不需要常驻监听进程还能在服务启动时用链上事件反推数据库遗漏的记录。5. 答辩验收时怎么自证“数据没被篡改”一台笔记本做闭环验证毕业设计答辩只有十几分钟没法带评委去跑一遍完整区块链浏览器链。我建议把“不可篡改”这个抽象概念转成一个可演示的对照实验全程只需要一台笔记本和Ganache界面。实验步骤分为三步。第一步在MySQL里直接改掉score表的数据比如把一个80分改成95分。第二步调用系统的“链上校验”接口新接口会查一次合约getProject并把链上平均分拉出来。第三步Ganache界面不用关直接把评分交易的历史记录翻给评委看。对比结果一目了然数据库里的分数可以随便改合约里的分数纹丝不动因为改动数据库不会产生新的交易链上状态根本不会跟着变。为了让对照更直观我建议在服务层加一个chain-check接口返回三个字段数据库分值、链上分值、是否一致。这个接口用到的校验逻辑很简单就是拿MySQL的score_sum和score_count除以后与getProject对比GetMapping(/chain-check/{projectId}) public MapString, Object check(PathVariable Long projectId) { ListProjectRecord records projectRecordMapper.findByProjectId(projectId); BigInteger[] project contract.getProject(BigInteger.valueOf(projectId)).send(); long dbAvg records.stream() .mapToLong(ProjectRecord::getScore) .average() .orElse(0); long chainAvg project[3].longValue(); MapString, Object result new HashMap(); result.put(dbAvg, dbAvg); result.put(chainAvg, chainAvg); result.put(consistent, dbAvg chainAvg); return result; }这个接口本身不需要多复杂但很适合作为答辩演示的“钩子”评委追问“你凭什么说链上不可篡改”时现场改动数据库再刷新这个接口比任何口头解释都有说服力。如果时间充裕还有一个可选的加分项——定期对账任务。每天晚上扫描一次所有已结束评审的项目把数据库汇总与链上平均分做比对不一致就发告警。这个设计虽然不产生新的区块链能力但它展示了生产环境里“链上真实性校验”的常见用法。我自己的习惯是在答辩前跑一遍自检脚本先重置Ganache再部署新合约然后把日志头部的“网络ID、合约地址、管理员地址”三行截图留档。有一回我跳过了这个步骤现场演示时发现配置文件里还是旧合约地址整场Demo全部打了水漂。从那以后我再也不敢省略这三行核对。坦诚说这个题目的工作量不算小但它把“区块链”从一个抽象名词变成了可以亲手验证的系统做完以后你对Web3j和交易生命周期会建立非常具体的直觉。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/18 12:41:16 · 阅读 1.2k SpringBoot+以太坊评审系统：链上存证与防篡改实战
简介面向计算机相关专业毕业设计场景这份资源提供了基于Spring Boot与以太坊的项目评审系统完整方案涵盖系统源码、部署文档与项目配套资料可支撑毕业设计、课程设计、实训演示以及项目初期立项等多种用途。包体共收录二百零八个文件压缩后大小约为七百七十一KB其中Java源码承担后端业务逻辑JavaScript脚本与FreeMarker页面模板及CSS样式共同搭建前端展示GIF动画可直观呈现运行效果SQL脚本用于初始化数据库Solidity合约及ABI和BIN文件对应以太坊链上交互从界面操作到智能合约调用均有对应素材适合完整研读与二次开发。当前已有约一百一十人学习下载。据资源说明该项目为高分完整源码答辩得分九十五分且已测试运行适合软件工程、区块链、人工智能等专业在校师生解压可获得可部署的工程结构、智能合约交互实现、部署文档与项目资料内容预览含构建脚本及登录注册页面能够减少环境搭建与界面理解成本若有编程基础可在此基础上扩展评审流程或权限模块是快速上手区块链应用开发的高质量参考。1. 基于SpringBoot和以太坊的评审系统真正的加分项是“哪些地方不上链”区块链毕业设计里最容易翻车的做法是开发者兴奋地把项目材料、专家信息、打分理由全部塞进智能合约结果Gas费高得离谱、界面卡成幻灯片答辩时还被老师问住。基于SpringBoot以太坊做项目评审系统核心卖点从来不是“用区块链替代数据库”而是让评审过程中最容易被质疑的环节——项目提交时间、专家评分、状态流转——变成链上交易。交易哈希、区块号、时间戳全部公开可查评审结果改了也赖不掉。这篇文章会按我实际做这类系统的顺序展开先划清链上和链下的边界再写合约、用Web3j把合约变成SpringBoot接口最后给出部署和答辩验证的具体路径。适合正在定题的毕设同学也适合想给老评审系统加一层“存证外挂”的开发者。2. 把评审流程拆成链上与链下先想清楚边界再动手写合约2.1 评审系统为什么选择“链上存证”而不是“链上跑完整业务”项目评审业务的本质是发起方提交项目→组织方分配专家→专家打分→汇总结果。传统SpringBoot系统用一张score表和一个状态字段就能做完整套流程但有个没法回避的问题数据库管理员可以改分项目方可以质疑某个专家是否真的在那个时间点提交了评分。而区块链能解决的不是“自动化评审”是“证据固化”——把每一次关键操作变成一笔交易交易里带上调用者地址和时间戳任何人可以通过区块浏览器或者Ganache的交易列表看到它。所以我在给A同学做这个毕设题目时第一件事不是打开IDE写代码而是画一张数据边界表。需要上链的是项目Id、提交者地址、提交时间、专家地址列表、每个专家的评分、项目最终状态。不需要上链的是项目文档原文、专家姓名、评审意见文本、通知记录。这些留在MySQL里通过projectId与链上数据关联。这样设计的好处是合约保持轻量业务功能仍然用SpringBoot的成熟能力实现区块链只负责“记账”。2.2 为什么选以太坊而不是Fabric或自研链毕业设计需要“看得见的交易”我见过不少同学一开始想用Fabric理由是“联盟链效率高”。但Fabric的部署依赖Docker镜像、排序节点、组织证书一套环境折腾两个星期是常态而且Fabric没有一个像Ganache这样双击就能跑的图形化链。以太坊的优势在于开发体验Ganache启动后自带十个账户、每个账户100个测试币还能在界面里直接看到每笔交易流入哪个区块这对答辩演示非常友好。另一个更实际的原因是资源网上能找到的中文资料、博客、错误修复帖绝大多数都是以太坊Web3j方向遇到问题搜索成本低。安全方面要提醒一句测试网络的私钥只用于本地演示千万不要把它当成正式环境使用。整个开发期我只需要一条本地私链配置很简单网络ID用5777端口7545Gas上限默认就行。这个网络配置会让后续所有合约交互代码复用同一套参数。2.3 合约数据模型状态枚举、项目结构、评分记录的映射关系写合约之前先把数据结构想清楚。我用的核心模型是这样的数据对象所在位置关键字段说明评审项目合约projectId、title、state、scoreSum、scoreCount状态和分数汇总在链上评审专家合约address、projectId、hasVoted专家地址作为唯一身份原始材料MySQLprojectId、fileUrl、description只存业务信息不上链链上索引MySQLprojectId、txHash、blockNumber关联链上和链下合约里用枚举表示评审状态状态变迁是单向的待评审(0)→评审中(1)→已结束(2)。这个状态机的好处是杜绝了“评审结束后重新打分”的操作——合约会检查当前状态只有处于评审中时才能提交评分。每次打分事件里记录评委地址和分数最终汇总交给合约计算平均分避免有人篡改MySQL里的score字段。因为评审专家被限制为只有管理员添加进白名单的地址这个合约不需要实现复杂的权限判断一个onlyOwner修饰符就可以覆盖大多数流转场景。3. SpringBootWeb3j落地从Ganache到REST接口一条链路走通3.1 初始化工程依赖只要三组版本别追新创建SpringBoot项目时pom.xml里加入Web3j、Spring Web和MySQL驱动就够了。版本搭配上我用的是SpringBoot 2.7.x配合Web3j 4.8.x这个组合兼容Java 8和11网上踩坑资料也最全。不要一上来就追Web3j 4.9以上它对Java 17和SpringBoot 3做了调整反而容易引入不必要的报错。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.12/version /parent properties java.version1.8/java.version web3j.version4.8.8/web3j.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.web3j/groupId artifactIdcore/artifactId version${web3j.version}/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency /dependenciesWeb3j的core依赖会带入okhttp作为HTTP客户端它负责与Ganache的7545端口通信。SpringBoot的Parent管理了大部分依赖版本但Web3j需要单独声明版本否则Maven会给你拉一个非常旧的版本旧版本的ABI解码方式和现在写的Solidity 0.8.x合约不兼容这是第一个容易埋雷的地方。3.2 编写ReviewSystem.sol只留四个函数合约我只实现了四个核心函数提交项目、分配专家、提交评分、查询项目。项目登记做成管理员代提交的方式因为毕设场景里往往是管理员统一录入项目信息而不是让每个学生在链上自己注册钱包这样也减少了前端对接的复杂度。// SPDX-License-Identifier: MIT pragma solidity ^0.8.7; contract ReviewSystem { enum ReviewState { Pending, Reviewing, Closed } struct Project { string title; uint256 submitTime; ReviewState state; uint256 scoreSum; uint256 scoreCount; } address public owner; mapping(uint256 Project) public projects; mapping(uint256 mapping(address bool)) public hasVoted; mapping(uint256 address[]) private reviewers; event ProjectSubmitted(uint256 projectId, string title, uint256 submitTime); event ReviewerAssigned(uint256 projectId, address reviewer); event ScoreSubmitted(uint256 projectId, address reviewer, uint256 score); modifier onlyOwner() { require(msg.sender owner, not owner); _; } constructor() { owner msg.sender; } function submitProject(uint256 projectId, string calldata title) external onlyOwner { require(projects[projectId].submitTime 0, existing project); projects[projectId] Project({ title: title, submitTime: block.timestamp, state: ReviewState.Pending, scoreSum: 0, scoreCount: 0 }); emit ProjectSubmitted(projectId, title, block.timestamp); } function assignReviewer(uint256 projectId, address reviewer) external onlyOwner { Project storage p projects[projectId]; require(p.state ReviewState.Pending, wrong state); require(reviewer ! address(0), zero address); reviewers[projectId].push(reviewer); p.state ReviewState.Reviewing; emit ReviewerAssigned(projectId, reviewer); } function submitScore(uint256 projectId, uint256 score) external { require(score 0 score 100, invalid score); Project storage p projects[projectId]; require(p.state ReviewState.Reviewing, not reviewing); require(!hasVoted[projectId][msg.sender], already voted); hasVoted[projectId][msg.sender] true; p.scoreSum score; p.scoreCount 1; emit ScoreSubmitted(projectId, msg.sender, score); } function getProject(uint256 projectId) external view returns (string memory title, uint256 submitTime, uint256 state, uint256 avgScore, uint256 scoreCount) { Project storage p projects[projectId]; uint256 avg 0; if (p.scoreCount 0) { avg p.scoreSum / p.scoreCount; } return (p.title, p.submitTime, uint256(p.state), avg, p.scoreCount); } }合约里有个值得注意的代码习惯状态检查放在业务逻辑之前所有可能失败的调用先require再改状态这样能避免“校验失败但状态被污染”的中间态。参数方面score限制在0到100之间平均分用整数除法计算答辩时可以说清楚“链上只存整数分数统计精度由链下处理”不必为了浮点数把合约做复杂。每个函数都抛出对应的事件事件参数里的projectId和reviewer是后续做索引查询的关键。3.3 编译、生成Java包装类两条命令拉通写好的sol文件需要编译成ABI和二进制。我用的是Solidity编译器的命令行版本# 安装编译器macOS为例具体以你的环境为准 npm install -g solc # 编译输出ABI和bin solc --optimize --bin --abi ReviewSystem.sol -o build/contracts编译成功后build/contracts目录下会有ReviewSystem.abi和ReviewSystem.bin两个文件。接下来用Web3j的命令行工具生成Java包装类这一步会把合约的函数、事件、结构体映射成Java类型。web3j generate solidity -b build/contracts/ReviewSystem.bin \ -a build/contracts/ReviewSystem.abi \ -o src/main/java \ -p com.demo.blockchain.contract参数里-o是输出目录-p是包名。常见的错误是路径分隔符在Windows下用了反斜杠建议在项目根目录执行并让build/contracts保持相对路径。生成后会出现一个ReviewSystem.java里面包含部署方法、每个合约函数的Java封装还有事件类。Web3j对Solidity struct的返回值处理比较特殊getProject会变成一个包含多个字段的Java对象列表下标依次对应返回值顺序建议在服务层把它封装成DTO别直接把数组暴露给前端。3.4 合约部署工具类把地址、网络ID、管理员私钥做成可配置项部署合约最稳妥的方式不是手动操作而是写一个CommandLineRunner启动任务在SpringBoot启动时读取配置并自动部署。这样每次Ganache重置后重新启动项目就能自动部署新合约并打印地址。Component public class ContractDeployRunner implements CommandLineRunner { Value(${blockchain.ethereum.rpc-url}) private String rpcUrl; Value(${blockchain.ethereum.private-key}) private String privateKey; Override public void run(String... args) throws Exception { Web3j web3j Web3j.build(new HttpService(rpcUrl)); Credentials credentials Credentials.create(privateKey); ContractGasProvider gasProvider new StaticGasProvider( BigInteger.valueOf(3000000L), BigInteger.valueOf(20000000000L) ); ReviewSystem contract ReviewSystem.deploy( web3j, credentials, gasProvider).send(); System.out.println(contract address: contract.getContractAddress()); } }静态Gas提供者的两个参数分别是Gas上限和Gas价格。Ganache默认Gas价格是20 Gwei也就是20000000000这是本地网络的默认值写进配置即可。部署输出的地址必须记录到application.yml里后面所有业务接口都依赖这个地址。这里我建议把地址打印和保存做成一步部署成功后自动写入配置文件而不是靠手工复制。手工复制是必然翻车的环节后文避坑章会专门展开。3.5 业务服务层把合约调用变成REST接口处理好链下索引服务层的核心是把合约操作包成ReviewContractService对外提供submitProject、assignReviewer、submitScore、getScoreSummary四个方法。以提交评分为例Service public class ReviewContractService { private final Web3j web3j; private final ReviewSystem contract; private final String adminPrivateKey; public ReviewContractService( Value(${blockchain.ethereum.rpc-url}) String rpcUrl, Value(${blockchain.ethereum.contract-address}) String contractAddress, Value(${blockchain.ethereum.private-key}) String adminPrivateKey) { this.web3j Web3j.build(new HttpService(rpcUrl)); this.contract ReviewSystem.load( contractAddress, web3j, Credentials.create(adminPrivateKey), new StaticGasProvider( BigInteger.valueOf(3000000L), BigInteger.valueOf(20000000000L))); this.adminPrivateKey adminPrivateKey; } public TransactionReceipt submitScore(Long projectId, Integer score) { try { TransactionReceipt receipt contract .submitScore(BigInteger.valueOf(projectId), BigInteger.valueOf(score)) .send(); if (!receipt.isStatusOK()) { throw new RuntimeException(chain transaction failed); } return receipt; } catch (Exception e) { throw new RuntimeException(submitScore on chain error, e); } } }加载合约时我用的ReviewSystem.load它和部署的区别在于不会重新发布合约只是创建本地代理对象每次调用都会构造一个交易发到Ganache。TransactionReceipt里的isStatusOK()用来判断交易是否被链上接受但这里有个容易误判的点send()本身可能因为Gas不足直接抛异常这时候要看异常类型是TransactionException还是RuntimeException前者通常是链上执行回滚后者才是网络或编码问题。服务层拿到回执后要同步把txHash和blockNumber存进MySQL的chain_record表这样评审记录既能在业务页面上展示也能随时回溯到链上验证。4. 最常见的5个坑现象、原因、解决4.1 致命问题合约地址没更新所有接口静默失败一名开发者在演示前重新部署了合约Ganache弹出了新地址但application.yml里的contract-address还是旧值。启动项目后所有接口都返回“transaction failed”而且日志里看不到合约级别的错误因为load一个不存在的地址在Web3j里不算异常交易发送后Ganache会因为合约地址无代码而执行回滚。解决方法是把部署和配置更新做成一个动作。我的做法是写一个脚本先启动Ganache再运行一个仅部署用的测试类部署成功后把地址直接写回application.yml最后才启动SpringBoot主类。三个步骤固定顺序谁也不能跳过。4.2 中文乱码合约返回值在页面里变成问号Solidity的string本质是UTF-8编码的动态字节数组Web3j解析后会交给Java的String对象本身不会乱码。真正导致乱码的是SpringBoot默认的HTTP响应编码和数据库连接串没指定characterEncodingutf-8。现象是合约查出来的标题正常但从MySQL取出来的材料描述乱码两者混在一起就显得“区块链有问题”。原因在链路的不同节点Web3j返回的String已经是正确的Java Unicode字符串问题出在SpringBoot的server.servlet.encoding配置和JDBC URL参数。解决方法是三处同时设置application.yml里配置UTF-8编码JDBC连接串加上useUnicodetruecharacterEncodingutf8前端页面通过meta charsetutf-8声明编码。这样排查有个顺序先确认合约查询接口返回的JSON是否正常再检查后续环节不要在合约里做十六进制编码的过度设计。4.3 nonce太低重启Ganache后连续报错Ganache每次重置链上账户的交易计数会清零。但如果SpringBoot进程没有重启Web3j内部会缓存上一轮会话的nonce再次发送交易时nonce比链上状态高Ganache直接返回“nonce too low”。现象是重启网络后的第一笔交易必失败第二笔偶尔成功之后完全错乱。解决方法是每次发送交易前显式获取最新nonceEthGetTransactionCount count web3j .ethGetTransactionCount(credentials.getAddress(), DefaultBlockParameterName.PENDING) .send(); BigInteger nonce count.getTransactionCount();4.4 Gas预估不足界面显示失败交易却已经上链合约里遍历评委列表或存储较长字符串时实际消耗的Gas可能超过手动设置的300万上限。Web3j抛出的TransactionException会让接口报错但Ganache里已经产生了交易记录状态是0x0导致数据库里没有索引记录链上却有失败的痕迹。解决方式是用ethEstimateGas先预估再乘以安全系数作为GasLimitEthEstimateGas estimate web3j .ethEstimateGas(transaction) .send(); BigInteger gasLimit estimate .getAmountUsed() .multiply(BigInteger.valueOf(2L));这也是为什么我在部署工具类里用StaticGasProvider而不是写死在合约代码里的原因——GasLimit应该可以在配置文件中调整而不是每次改合约都要重新编译。4.5 事件监听错位服务重启后丢历史事件很多资料里用ethSubscribe做实时监听但订阅模式的限制是它只接收订阅之后产生的事件。开发中重启SpringBoot是常态重启前已经上链的评分事件会丢失前端统计列表和合约里的实际数据不一致。最常见的翻车场景是专家投完分后服务重启页面评分记录不显示但合约平均分是包含这一票的。解决方法是改用getPastEvents从指定区块重新扫描ListReviewSystem.ScoreSubmittedEventResponse events contract.getScoreSubmittedEvents( new DefaultBlockParameterNumber(0L), new DefaultBlockParameterName(latest) );首次运行时扫描全部区块之后每次启动记录上次处理的blockNumber从那个区块继续增量扫描。这个方案不需要常驻监听进程还能在服务启动时用链上事件反推数据库遗漏的记录。5. 答辩验收时怎么自证“数据没被篡改”一台笔记本做闭环验证毕业设计答辩只有十几分钟没法带评委去跑一遍完整区块链浏览器链。我建议把“不可篡改”这个抽象概念转成一个可演示的对照实验全程只需要一台笔记本和Ganache界面。实验步骤分为三步。第一步在MySQL里直接改掉score表的数据比如把一个80分改成95分。第二步调用系统的“链上校验”接口新接口会查一次合约getProject并把链上平均分拉出来。第三步Ganache界面不用关直接把评分交易的历史记录翻给评委看。对比结果一目了然数据库里的分数可以随便改合约里的分数纹丝不动因为改动数据库不会产生新的交易链上状态根本不会跟着变。为了让对照更直观我建议在服务层加一个chain-check接口返回三个字段数据库分值、链上分值、是否一致。这个接口用到的校验逻辑很简单就是拿MySQL的score_sum和score_count除以后与getProject对比GetMapping(/chain-check/{projectId}) public MapString, Object check(PathVariable Long projectId) { ListProjectRecord records projectRecordMapper.findByProjectId(projectId); BigInteger[] project contract.getProject(BigInteger.valueOf(projectId)).send(); long dbAvg records.stream() .mapToLong(ProjectRecord::getScore) .average() .orElse(0); long chainAvg project[3].longValue(); MapString, Object result new HashMap(); result.put(dbAvg, dbAvg); result.put(chainAvg, chainAvg); result.put(consistent, dbAvg chainAvg); return result; }这个接口本身不需要多复杂但很适合作为答辩演示的“钩子”评委追问“你凭什么说链上不可篡改”时现场改动数据库再刷新这个接口比任何口头解释都有说服力。如果时间充裕还有一个可选的加分项——定期对账任务。每天晚上扫描一次所有已结束评审的项目把数据库汇总与链上平均分做比对不一致就发告警。这个设计虽然不产生新的区块链能力但它展示了生产环境里“链上真实性校验”的常见用法。我自己的习惯是在答辩前跑一遍自检脚本先重置Ganache再部署新合约然后把日志头部的“网络ID、合约地址、管理员地址”三行截图留档。有一回我跳过了这个步骤现场演示时发现配置文件里还是旧合约地址整场Demo全部打了水漂。从那以后我再也不敢省略这三行核对。坦诚说这个题目的工作量不算小但它把“区块链”从一个抽象名词变成了可以亲手验证的系统做完以后你对Web3j和交易生命周期会建立非常具体的直觉。希望帮到你。本文还有配套的精品资源点击获取