简介这是一套面向高校毕业设计、期末大作业及课程设计场景的基于区块链的证书管理系统源码与配套数据包解决证书可信存证与高效验真的工程实现问题难度适中适合具备一定 Java 与区块链基础的学习者参考。压缩包内含 67 个文件、总大小约 131KB核心为 49 个 Java 源码文件覆盖系统业务逻辑与区块链相关实现另有 XML 配置文件、properties/yml 配置、Maven 启动脚本以及证书密钥相关文件配套较完整。资料评审分达 98 分且源码经本地编译可运行可直接导入开发环境进行功能验证与二次开发。内容包含项目目录结构、公私钥证书与 sol 合约文件等便于理解证书签发、链上存储和校验流程。目前已有 84 人浏览学习适合用作毕业设计选题参考、系统设计文档撰写对照和区块链应用开发入门练习。1. 为什么区块链证书管理系统能解决验真难HR 拿一份证书扫描件去官网验真接口返回“查无此证”高校把证书做成二维码扫开只是张图片PS 一样能以假乱真。证书管理的关键从来不是防伪印刷而是验证可信。基于区块链的证书管理系统源码给出的答案是把证书的哈希摘要写进一条不可篡改的链上验真时重算哈希与链上记录比对原文被改立刻就露馅。这套资源是完整可运行的毕业设计源码Spring Boot Maven 构建目录自带 mvnw.cmd 与 pom.xml本地编译通过、评审 98 分覆盖证书签发、哈希上链、在线验证、用户权限的完整闭环。适合毕业设计、期末大作业、课程设计做闭环参考。下面按工程结构、上链设计、签发实现、验证实战、部署排错的顺序拆。2. 工程结构与链上链下双库设计一个典型的区块链证书管理系统代码要分三层看Web 接口层负责签发与验证的 HTTP 出入口业务层负责组装证书数据、计算哈希、调用链服务链服务层维护区块与整链校验。把这三层拆清楚后面所有功能都是在它们之间传参数、加状态机。2.1 从 pom.xml 与 mvnw.cmd 看工程骨架解压 System-main 后能看到 Maven 标准布局与 Wrapper 脚本同时存在System-main ├── pom.xml # 依赖与打包配置 ├── mvnw # Linux/macOS 下的 Maven Wrapper ├── mvnw.cmd # Windows 下的 Maven Wrapper ├── .gitignore # Git 过滤规则 ├── .mvn/wrapper # Wrapper 元数据 └── src ├── main # 主代码java 与 resources └── test # 单元测试与链自检pom.xml 里通常是 spring-boot-starter-web、mybatis、mysql-connector-java、lombok 这几类坐标具体版本以源码为准。Maven Wrapper 的意义在于团队协作时不需要每个人本地装同一版本 Maven直接./mvnw clean package就能拉取指定版本构建Windows 下对应执行mvnw.cmd。评审时问“为什么带 Wrapper 而不是直接用系统 Maven”答“保证构建环境一致”就是标准得分点。2.2 链下存原文、链上存哈希的分层模型这套系统采用“双库”设计MySQL 存证书明文供检索展示区块链只存证书哈希摘要。这样做的直接原因是成本和隐私——证书正文动辄几百字节还有附件 PDF全部上链既慢又贵而哈希摘要长度固定为 64 位十六进制足以证明“这份原件在某个时间点确实存在过”。数据存储位置内容作用证书明文MySQL编号、持有人、签发机构、日期快速检索、前端展示存证摘要区块链certHash 时间戳 prevHash防篡改、可验真映射关系MySQLcert_no ↔ block_hash验证时定位区块明文在 MySQL 里摘要上链二者通过证书编号关联。这层设计答辩时常被追问“为什么不把全文上链”回答“链上只解决信任问题不解决存储问题”即可。2.3 区块数据结构与哈希链校验链的核心是一个 Block 类与一个 BlockChain 类。Block 的字段设计直接决定链能不能防篡改public class Block { private int index; // 区块高度从 0 开始 private long timestamp; // 出块时间戳毫秒 private String prevHash; // 前序区块哈希形成链式结构 private String data; // 业务数据证书哈希 private String hash; // 本区块哈希 private int nonce; // 出块随机数用于调整哈希 public String computeHash() { return SHA256Util.sha256( index | timestamp | prevHash | data | nonce); } }index 用来标识区块位置timestamp 记录上链时间prevHash 把每个区块串成链nonce 是内容不变时改变哈希的调节参数。computeHash 里拼接顺序必须固定拼接内容里任一个字段变化最终哈希都完全不同。链的完整性校验是验证模块的地基public boolean isChainValid() { if (blocks.isEmpty()) return false; if (!blocks.get(0).getHash().equals(blocks.get(0).computeHash())) { return false; // 创世块被篡改 } for (int i 1; i blocks.size(); i) { Block cur blocks.get(i); Block prev blocks.get(i - 1); if (!cur.getHash().equals(cur.computeHash())) { return false; // 当前块数据被改 } if (!cur.getPrevHash().equals(prev.getHash())) { return false; // 链接关系被破坏 } } return true; }这段代码做了三类检查创世块哈希是否一致、每个区块的哈希是否等于内部字段重算结果、相邻区块的 prevHash 是否衔接。只要有人改过链上任一区块的 data、timestamp 或 nonce从那个位置往后所有校验都会失败。这也是传统“改一条 UPDATE 语句”与区块链方案的本质区别——篡改成本从一条 SQL 变成了重算整条链。3. 证书签发与哈希上链的核心实现签发是系统的入口流程可以概括为“归一化字段 → 计算 SHA-256 → 生成区块 → 落库”。这个顺序不能乱顺序错了验证阶段必然出问题。3.1 证书哈希的计算规则证书哈希不是简单地对整个对象做序列化而是要固定字段顺序和拼接分隔符public String calcCertHash(Certificate cert) { String source String.join(|, cert.getCertNo(), cert.getHolderName(), cert.getIssuer(), cert.getIssueDate().toString(), cert.getContentHash()); // 附件 PDF 的哈希 return SHA256Util.sha256(source); }字段顺序固定为“编号、持有人、机构、日期、附件哈希”中间用竖线分隔。附件哈希单独计算再拼进来是为了防止“正文没改但替换了附件”的绕过方式。这里最容易踩的坑是前后端或不同服务各写一套拼接规则导致计算出的哈希不一致。源码里通常有一个独立的 SHA256Util 工具类签发和验证必须共用同一个。3.2 签发接口参数校验、上链、落库的顺序签发接口的典型实现如下Transactional public String issue(CertIssueRequest req) { // 1 参数校验持有人、签发机构、附件必填 if (req.getHolderName() null || req.getIssuer() null) { throw new BizException(持有人与签发机构不能为空); } // 2 生成证书号机构前缀 年份 流水 String certNo genCertNo(req.getIssuer()); Certificate cert new Certificate(); cert.setCertNo(certNo); cert.setHolderName(req.getHolderName()); cert.setIssuer(req.getIssuer()); cert.setIssueDate(LocalDateTime.now()); // 3 计算证书哈希并写入对象 cert.setHash(calcCertHash(cert)); // 4 上链生成新区块 Block block chainService.appendBlock(cert.getHash()); // 5 落库保存明文与链上映射 certMapper.insert(cert); chainMapper.saveMapping(certNo, block.getHash(), block.getIndex()); return certNo; }注意第 4、5 步的顺序问题链服务如果是内存或本地文件实现不参与 Spring 事务数据库回滚时链上并不会撤销。项目里常见做法是“先落库再异步上链”失败后由补偿任务清理孤儿区块也有简单实现直接先上链后落库但注释里必须写明数据不一致时的处理策略。答辩时能主动说出这个顺序代价比代码跑通更加分。3.3 并发签发与区块追加的同步处理本地链的 appendBlock 必须考虑并发。多个请求同时签发如果没加锁两个新区块可能拿到同一个 indexpublic synchronized Block appendBlock(String data) { Block prev blocks.get(blocks.size() - 1); Block block new Block(prev.getIndex() 1, prev.getHash(), data); blocks.add(block); return block; }synchronized 保证同一时刻只有一个线程能追加区块index 连续、prevHash 正确。真实区块链里这个职责由共识算法承担本地链用 JVM 锁模拟即可。后续如果换 Fabric 或以太坊实现只需要把 appendBlock 内部换成智能合约调用对上层 service 的接口签名透明。环节失败场景影响处理方式参数校验空持有人脏数据上链前置拦截不放行哈希计算字段顺序不一致验证必然失败统一归一化工具类区块追加链文件损坏整链校验失败备份链文件落库数据库闪断有链无证补偿对账任务4. 证书验证与链上查询实战验证是证书管理系统的门面也是公开展示时最能体现实战感的模块。一个被验证的证书至少要过三道关。4.1 验真接口的三重比对逻辑验证接口接收证书编号返回证书详情或篡改提示GetMapping(/api/cert/verify) public ApiResult verify(RequestParam String certNo) { // 1 查明文编号不存在直接拒绝 Certificate cert certMapper.selectByCertNo(certNo); if (cert null || cert.getStatus() ! 1) { return ApiResult.fail(证书编号不存在或已撤销); } // 2 重算哈希先和库中哈希比对 String recalc calcCertHash(cert); if (!recalc.equals(cert.getHash())) { return ApiResult.fail(证书内容与签发时不一致); } // 3 定位区块校验链上数据 ChainRecord record chainMapper.selectByCertNo(certNo); Block block chainService.getByHash(record.getBlockHash()); if (!cert.getHash().equals(block.getData()) || !chainService.isChainValid()) { return ApiResult.fail(链上验签失败); } return ApiResult.ok(CertView.from(cert)); }三重校验分别防住三种攻击路径第一步防编号伪造第二步防 MySQL 被直接改字段第三步防链上区块被替换或整条链被回滚重建。接口是公开的所以内部异常细节不能外抛统一返回“验证失败”或“内容不一致”避免把链结构与不合规报错信息泄露给调用方。4.2 数据库表设计与基础 DDL与本模块直接相关的两张核心表如下CREATE TABLE cert_certificate ( id BIGINT PRIMARY KEY AUTO_INCREMENT, cert_no VARCHAR(64) UNIQUE NOT NULL COMMENT 证书编号, holder_name VARCHAR(64) NOT NULL COMMENT 持有人, issuer VARCHAR(128) NOT NULL COMMENT 签发机构, issue_date DATETIME NOT NULL COMMENT 签发时间, expire_date DATETIME NULL COMMENT 有效期, cert_hash CHAR(64) NOT NULL COMMENT SHA-256 哈希, status TINYINT NOT NULL DEFAULT 1 COMMENT 1有效 0撤销 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE cert_chain_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, cert_no VARCHAR(64) NOT NULL COMMENT 证书编号, block_hash VARCHAR(64) NOT NULL COMMENT 关联区块哈希, block_index INT NOT NULL COMMENT 区块高度, create_time DATETIME NOT NULL COMMENT 上链时间, UNIQUE KEY uk_cert_block (cert_no, block_hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;cert_hash 字段是冗余存储作用是让验证流程先做廉价比对不一致时直接返回省一次链查询。cert_chain_record 是证书与区块的映射表验证时通过 cert_no 反查 block_hash再去链上比对 data。两张表都用 utf8mb4避免中文持有人姓名出现乱码导致哈希对不上。4.3 REST 接口清单与权限约定接口方法关键参数返回权限/api/cert/issuePOSTholderName, issuer, contentHashcertNo管理员/api/cert/verifyGETcertNo证书信息 / 失败原因公开/api/chain/blocksGETpage, size分页区块列表公开/api/chain/blocks/{hash}GEThash区块详情与交易列表公开签发接口必须走登录与角色校验防止任何人都能给自己签发一张“某大学证书”。验证接口和链查询接口要放行因为验真是面向公众的。常见做法是在 WebConfig 里配置拦截器放行路径签发走 Sa-Token 或 Spring Security 的注解鉴权链浏览接口做成只读的分页查询不提供任何写操作入口。5. 本地编译运行与高频踩坑5.1 从 mvnw.cmd 到 curl 的启动自检cd System-main ./mvnw clean package -DskipTests java -jar target/xxx.jar # jar 名以 target 下实际产物为准 curl http://localhost:8080/api/cert/verify?certNoCP20240001Windows 下用mvnw.cmd clean package。启动前先核对 application.yml 里的 MySQL 账号密码把数据库建好否则启动时数据源初始化直接失败。5.2 常见报错与处理现象原因处理连接数据库失败库未创建或密码不对核对 yml 并建库哈希总对不上字段拼接顺序不一致检查是否共用工具类提示链上验签失败链数据文件损坏备份后重新初始化创世块8080 端口占用本地环境冲突改 server.port 后重启提示改过证书实体字段后老数据必须重新签发或用脚本重算哈希否则旧证书必然验证不过。把数据库当唯一真相源、不同步更新链上摘要是这个项目里最常见的失误。用 curl 复验一次确认返回的 holderName 与签发日期与签发时一致再继续改前端页面。本文还有配套的精品资源点击获取 区块链证书管理系统源码实现：哈希上链与防篡改验证
简介这是一套面向高校毕业设计、期末大作业及课程设计场景的基于区块链的证书管理系统源码与配套数据包解决证书可信存证与高效验真的工程实现问题难度适中适合具备一定 Java 与区块链基础的学习者参考。压缩包内含 67 个文件、总大小约 131KB核心为 49 个 Java 源码文件覆盖系统业务逻辑与区块链相关实现另有 XML 配置文件、properties/yml 配置、Maven 启动脚本以及证书密钥相关文件配套较完整。资料评审分达 98 分且源码经本地编译可运行可直接导入开发环境进行功能验证与二次开发。内容包含项目目录结构、公私钥证书与 sol 合约文件等便于理解证书签发、链上存储和校验流程。目前已有 84 人浏览学习适合用作毕业设计选题参考、系统设计文档撰写对照和区块链应用开发入门练习。1. 为什么区块链证书管理系统能解决验真难HR 拿一份证书扫描件去官网验真接口返回“查无此证”高校把证书做成二维码扫开只是张图片PS 一样能以假乱真。证书管理的关键从来不是防伪印刷而是验证可信。基于区块链的证书管理系统源码给出的答案是把证书的哈希摘要写进一条不可篡改的链上验真时重算哈希与链上记录比对原文被改立刻就露馅。这套资源是完整可运行的毕业设计源码Spring Boot Maven 构建目录自带 mvnw.cmd 与 pom.xml本地编译通过、评审 98 分覆盖证书签发、哈希上链、在线验证、用户权限的完整闭环。适合毕业设计、期末大作业、课程设计做闭环参考。下面按工程结构、上链设计、签发实现、验证实战、部署排错的顺序拆。2. 工程结构与链上链下双库设计一个典型的区块链证书管理系统代码要分三层看Web 接口层负责签发与验证的 HTTP 出入口业务层负责组装证书数据、计算哈希、调用链服务链服务层维护区块与整链校验。把这三层拆清楚后面所有功能都是在它们之间传参数、加状态机。2.1 从 pom.xml 与 mvnw.cmd 看工程骨架解压 System-main 后能看到 Maven 标准布局与 Wrapper 脚本同时存在System-main ├── pom.xml # 依赖与打包配置 ├── mvnw # Linux/macOS 下的 Maven Wrapper ├── mvnw.cmd # Windows 下的 Maven Wrapper ├── .gitignore # Git 过滤规则 ├── .mvn/wrapper # Wrapper 元数据 └── src ├── main # 主代码java 与 resources └── test # 单元测试与链自检pom.xml 里通常是 spring-boot-starter-web、mybatis、mysql-connector-java、lombok 这几类坐标具体版本以源码为准。Maven Wrapper 的意义在于团队协作时不需要每个人本地装同一版本 Maven直接./mvnw clean package就能拉取指定版本构建Windows 下对应执行mvnw.cmd。评审时问“为什么带 Wrapper 而不是直接用系统 Maven”答“保证构建环境一致”就是标准得分点。2.2 链下存原文、链上存哈希的分层模型这套系统采用“双库”设计MySQL 存证书明文供检索展示区块链只存证书哈希摘要。这样做的直接原因是成本和隐私——证书正文动辄几百字节还有附件 PDF全部上链既慢又贵而哈希摘要长度固定为 64 位十六进制足以证明“这份原件在某个时间点确实存在过”。数据存储位置内容作用证书明文MySQL编号、持有人、签发机构、日期快速检索、前端展示存证摘要区块链certHash 时间戳 prevHash防篡改、可验真映射关系MySQLcert_no ↔ block_hash验证时定位区块明文在 MySQL 里摘要上链二者通过证书编号关联。这层设计答辩时常被追问“为什么不把全文上链”回答“链上只解决信任问题不解决存储问题”即可。2.3 区块数据结构与哈希链校验链的核心是一个 Block 类与一个 BlockChain 类。Block 的字段设计直接决定链能不能防篡改public class Block { private int index; // 区块高度从 0 开始 private long timestamp; // 出块时间戳毫秒 private String prevHash; // 前序区块哈希形成链式结构 private String data; // 业务数据证书哈希 private String hash; // 本区块哈希 private int nonce; // 出块随机数用于调整哈希 public String computeHash() { return SHA256Util.sha256( index | timestamp | prevHash | data | nonce); } }index 用来标识区块位置timestamp 记录上链时间prevHash 把每个区块串成链nonce 是内容不变时改变哈希的调节参数。computeHash 里拼接顺序必须固定拼接内容里任一个字段变化最终哈希都完全不同。链的完整性校验是验证模块的地基public boolean isChainValid() { if (blocks.isEmpty()) return false; if (!blocks.get(0).getHash().equals(blocks.get(0).computeHash())) { return false; // 创世块被篡改 } for (int i 1; i blocks.size(); i) { Block cur blocks.get(i); Block prev blocks.get(i - 1); if (!cur.getHash().equals(cur.computeHash())) { return false; // 当前块数据被改 } if (!cur.getPrevHash().equals(prev.getHash())) { return false; // 链接关系被破坏 } } return true; }这段代码做了三类检查创世块哈希是否一致、每个区块的哈希是否等于内部字段重算结果、相邻区块的 prevHash 是否衔接。只要有人改过链上任一区块的 data、timestamp 或 nonce从那个位置往后所有校验都会失败。这也是传统“改一条 UPDATE 语句”与区块链方案的本质区别——篡改成本从一条 SQL 变成了重算整条链。3. 证书签发与哈希上链的核心实现签发是系统的入口流程可以概括为“归一化字段 → 计算 SHA-256 → 生成区块 → 落库”。这个顺序不能乱顺序错了验证阶段必然出问题。3.1 证书哈希的计算规则证书哈希不是简单地对整个对象做序列化而是要固定字段顺序和拼接分隔符public String calcCertHash(Certificate cert) { String source String.join(|, cert.getCertNo(), cert.getHolderName(), cert.getIssuer(), cert.getIssueDate().toString(), cert.getContentHash()); // 附件 PDF 的哈希 return SHA256Util.sha256(source); }字段顺序固定为“编号、持有人、机构、日期、附件哈希”中间用竖线分隔。附件哈希单独计算再拼进来是为了防止“正文没改但替换了附件”的绕过方式。这里最容易踩的坑是前后端或不同服务各写一套拼接规则导致计算出的哈希不一致。源码里通常有一个独立的 SHA256Util 工具类签发和验证必须共用同一个。3.2 签发接口参数校验、上链、落库的顺序签发接口的典型实现如下Transactional public String issue(CertIssueRequest req) { // 1 参数校验持有人、签发机构、附件必填 if (req.getHolderName() null || req.getIssuer() null) { throw new BizException(持有人与签发机构不能为空); } // 2 生成证书号机构前缀 年份 流水 String certNo genCertNo(req.getIssuer()); Certificate cert new Certificate(); cert.setCertNo(certNo); cert.setHolderName(req.getHolderName()); cert.setIssuer(req.getIssuer()); cert.setIssueDate(LocalDateTime.now()); // 3 计算证书哈希并写入对象 cert.setHash(calcCertHash(cert)); // 4 上链生成新区块 Block block chainService.appendBlock(cert.getHash()); // 5 落库保存明文与链上映射 certMapper.insert(cert); chainMapper.saveMapping(certNo, block.getHash(), block.getIndex()); return certNo; }注意第 4、5 步的顺序问题链服务如果是内存或本地文件实现不参与 Spring 事务数据库回滚时链上并不会撤销。项目里常见做法是“先落库再异步上链”失败后由补偿任务清理孤儿区块也有简单实现直接先上链后落库但注释里必须写明数据不一致时的处理策略。答辩时能主动说出这个顺序代价比代码跑通更加分。3.3 并发签发与区块追加的同步处理本地链的 appendBlock 必须考虑并发。多个请求同时签发如果没加锁两个新区块可能拿到同一个 indexpublic synchronized Block appendBlock(String data) { Block prev blocks.get(blocks.size() - 1); Block block new Block(prev.getIndex() 1, prev.getHash(), data); blocks.add(block); return block; }synchronized 保证同一时刻只有一个线程能追加区块index 连续、prevHash 正确。真实区块链里这个职责由共识算法承担本地链用 JVM 锁模拟即可。后续如果换 Fabric 或以太坊实现只需要把 appendBlock 内部换成智能合约调用对上层 service 的接口签名透明。环节失败场景影响处理方式参数校验空持有人脏数据上链前置拦截不放行哈希计算字段顺序不一致验证必然失败统一归一化工具类区块追加链文件损坏整链校验失败备份链文件落库数据库闪断有链无证补偿对账任务4. 证书验证与链上查询实战验证是证书管理系统的门面也是公开展示时最能体现实战感的模块。一个被验证的证书至少要过三道关。4.1 验真接口的三重比对逻辑验证接口接收证书编号返回证书详情或篡改提示GetMapping(/api/cert/verify) public ApiResult verify(RequestParam String certNo) { // 1 查明文编号不存在直接拒绝 Certificate cert certMapper.selectByCertNo(certNo); if (cert null || cert.getStatus() ! 1) { return ApiResult.fail(证书编号不存在或已撤销); } // 2 重算哈希先和库中哈希比对 String recalc calcCertHash(cert); if (!recalc.equals(cert.getHash())) { return ApiResult.fail(证书内容与签发时不一致); } // 3 定位区块校验链上数据 ChainRecord record chainMapper.selectByCertNo(certNo); Block block chainService.getByHash(record.getBlockHash()); if (!cert.getHash().equals(block.getData()) || !chainService.isChainValid()) { return ApiResult.fail(链上验签失败); } return ApiResult.ok(CertView.from(cert)); }三重校验分别防住三种攻击路径第一步防编号伪造第二步防 MySQL 被直接改字段第三步防链上区块被替换或整条链被回滚重建。接口是公开的所以内部异常细节不能外抛统一返回“验证失败”或“内容不一致”避免把链结构与不合规报错信息泄露给调用方。4.2 数据库表设计与基础 DDL与本模块直接相关的两张核心表如下CREATE TABLE cert_certificate ( id BIGINT PRIMARY KEY AUTO_INCREMENT, cert_no VARCHAR(64) UNIQUE NOT NULL COMMENT 证书编号, holder_name VARCHAR(64) NOT NULL COMMENT 持有人, issuer VARCHAR(128) NOT NULL COMMENT 签发机构, issue_date DATETIME NOT NULL COMMENT 签发时间, expire_date DATETIME NULL COMMENT 有效期, cert_hash CHAR(64) NOT NULL COMMENT SHA-256 哈希, status TINYINT NOT NULL DEFAULT 1 COMMENT 1有效 0撤销 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE cert_chain_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, cert_no VARCHAR(64) NOT NULL COMMENT 证书编号, block_hash VARCHAR(64) NOT NULL COMMENT 关联区块哈希, block_index INT NOT NULL COMMENT 区块高度, create_time DATETIME NOT NULL COMMENT 上链时间, UNIQUE KEY uk_cert_block (cert_no, block_hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;cert_hash 字段是冗余存储作用是让验证流程先做廉价比对不一致时直接返回省一次链查询。cert_chain_record 是证书与区块的映射表验证时通过 cert_no 反查 block_hash再去链上比对 data。两张表都用 utf8mb4避免中文持有人姓名出现乱码导致哈希对不上。4.3 REST 接口清单与权限约定接口方法关键参数返回权限/api/cert/issuePOSTholderName, issuer, contentHashcertNo管理员/api/cert/verifyGETcertNo证书信息 / 失败原因公开/api/chain/blocksGETpage, size分页区块列表公开/api/chain/blocks/{hash}GEThash区块详情与交易列表公开签发接口必须走登录与角色校验防止任何人都能给自己签发一张“某大学证书”。验证接口和链查询接口要放行因为验真是面向公众的。常见做法是在 WebConfig 里配置拦截器放行路径签发走 Sa-Token 或 Spring Security 的注解鉴权链浏览接口做成只读的分页查询不提供任何写操作入口。5. 本地编译运行与高频踩坑5.1 从 mvnw.cmd 到 curl 的启动自检cd System-main ./mvnw clean package -DskipTests java -jar target/xxx.jar # jar 名以 target 下实际产物为准 curl http://localhost:8080/api/cert/verify?certNoCP20240001Windows 下用mvnw.cmd clean package。启动前先核对 application.yml 里的 MySQL 账号密码把数据库建好否则启动时数据源初始化直接失败。5.2 常见报错与处理现象原因处理连接数据库失败库未创建或密码不对核对 yml 并建库哈希总对不上字段拼接顺序不一致检查是否共用工具类提示链上验签失败链数据文件损坏备份后重新初始化创世块8080 端口占用本地环境冲突改 server.port 后重启提示改过证书实体字段后老数据必须重新签发或用脚本重算哈希否则旧证书必然验证不过。把数据库当唯一真相源、不同步更新链上摘要是这个项目里最常见的失误。用 curl 复验一次确认返回的 holderName 与签发日期与签发时一致再继续改前端页面。本文还有配套的精品资源点击获取