简介一份面向计算机专业毕业设计的高分项目资料包聚焦基于区块链的医疗记录存储系统涵盖从需求分析、链码开发到系统部署的完整流程。适合正在准备毕设答辩、课程设计或期末大作业的学生也适合对区块链应用方向做项目实战的开发者。资源共207个文件约11.3MB核心包括java/go源码、yaml配置文件、pem/crt/priv_sk等证书密钥材料并配套sql数据库脚本、sh部署脚本以及答辩PPT、论文报告、中期报告、任务书等文字材料目录对源码、证书、脚本与文档做了区分便于按模块检索。目前已有275人学习下载能帮助读者快速理解区块链医疗记录上链存储、权限校验与前后端交互的实现思路。结合源码与论文讲解可顺利搭建可运行系统也为毕业设计文档撰写和答辩展示提供完整参考。1. 医疗记录不是不能上链而是不能“裸奔”上链电子病历散落在各家医院患者换一家医院就要重新做一遍检查医生看不到跨院病史纠纷发生时谁改过记录也无从追溯。基于区块链的医疗记录存储系统核心思路不是“把病历全文塞进区块”而是把“不可篡改的索引、授权和审计记录”放到链上把原文加密后放到链下。这个套路正好也是毕设评审最认可的组网方式区块链负责存证和权限普通存储负责文件和性能。这篇笔记会带你从选型开始把链码怎么写、数据怎么加密、IPFS怎么接、答辩怎么演示讲透。适合两类人正在选区块链毕设方向、需要源码和答辩材料支撑思路的学生以及想评估“区块链医疗存证”落地边界的技术从业者。2. 一条链、两张表、三段权限医疗记录存储系统的设计骨架2.1 为什么毕设级选型不上公链而选联盟链很多第一次做区块链方向的同学第一反应是“用以太坊写个智能合约”。以太坊的合约生态确实成熟但医疗记录这个场景有两个硬伤一是公有链上的数据所有节点可见明文病历上链相当于公开病史二是每次写入都要付燃料费读取性能也撑不起影像类大文件。联盟链是这类系统的常见选型我一般会优先推荐 Hyperledger Fabric。Fabric 的通道Channel机制天然做了数据隔离链码里的私有数据集合Private Data Collection可以把敏感字段只同步给授权节点节点准入由 MSPMembership Service Provider控制本身就适合医院、卫健委、保险机构这种多机构联盟。比较一下常见的四个落地方案方案数据可见性写入成本隐私改造量毕设落地难度以太坊 IPFS全节点可见每笔 Gas需要自行做访问控制中但隐私讲不清Fabric 通道仅通道内节点无燃料费通道 私有数据集低文档全FISCO BCOS机构准入无燃料费自带群组隔离中国内资料多自研 PoA 链自控无燃料费全部自己写高评审容易质疑Fabric 还有一个对毕设特别友好的点chaincode 支持用 Go 写和后续论文里的“系统设计”章节天然对应。你可以把链码类比成数据库里的存储过程把世界状态World State类比成一张 KV 表这样讲给非区块链背景的评审听阻力会小很多。2.2 两张核心表记录索引与授权记录把系统拆开看链上只需要两张“表”。第一张是医疗记录索引表med-record第二张是授权表med-auth。不要让链码背负存储 PDF、DICOM 影像这种重活它只负责回答三个问题这条记录存在吗、谁有权读、有没有被改过。我在链码里习惯用recordId作为主键值里存这样几个字段type MedicalRecord struct { RecordID string json:recordId // 记录编号全局唯一 PatientID string json:patientId // 患者编号关联链下用户中心 DoctorID string json:doctorId // 建档医生编号 RecordHash string json:recordHash // 加密后原文件的 SHA-256 DataRef string json:dataRef // 原文位置如 IPFS CID CreatedAt int64 json:createdAt // Unix 时间戳 UpdatedAt int64 json:updatedAt }这串字段设计里RecordHash是核心。无论原文放在 IPFS 还是云盘只要计算出 SHA-256 摘要写进状态事后取回文件再算一次哈希就能证明“内容没有被改动”。DataRef指向原文地址理论上是 IPFS CID实际毕设里也可以是服务器上的相对路径。授权表的结构稍微特殊一点它的值里必须带有效期type MedicalAuth struct { AuthID string json:authId // 授权编号 PatientID string json:patientId // 患者本人 DoctorID string json:doctorId // 被授权的医生 RecordID string json:recordId // 允许访问的记录 ExpireAt int64 json:expireAt // 过期时间Unix 时间戳 }这样设计的原因是病历的归属权一定在患者手里医生能否看某条记录不是由医生自己说了算而是由患者主动授权。把授权也上链就留下了完整的操作痕迹纠纷发生时审计链路是完整的。2.3 三段权限患者、医生、监管者各看到什么医疗记录系统的权限模型我一般会切成三段分别对应三种身份。患者段拥有完整权限能创建自己的授权、查看全部自己的记录、撤销已发出的授权。医生段只有处方权可以新建记录但读取别人的记录前必须先通过授权表的校验。患者 - 全量读写自己的记录索引可授权可撤销 医生 - 只写不改读取前校验 med-auth 授权和 ExpireAt 监管者 - 只读审计通过 GetHistoryForKey 查看记录变更历史这里有个细节容易写进论文里却实现不出来医生“新建记录”并不等于“拥有记录”。CreateRecord时写入的Owner仍然是患者 ID医生只是操作者DoctorID。后面做权限校验时判断条件就是“调用者 ID 是否等于 PatientID或存在未过期的授权记录”。后端接口层按这个模型拆成三组即可网关鉴权后把用户的身份信息放进 JWT再透传给 SDK 调链码时带上证书和 MSP ID。这样从链码到接口权限规则是同一套答辩时被追问权限漏洞也能答得连贯。3. 用 Fabric 2.2 在本地跑通最小医疗链码命令、参数与背书策略3.1 环境三件套与 test-network 启动命令Fabric 的开发环境说简单也简单说麻烦也麻烦。最简单可靠的方式是直接用官方 Docker 镜像和fabric-samples仓库里的test-network不要自己手动装 peer、orderer 二进制。我一般会在 Ubuntu 22.04 上先把三件套装好Docker、Docker Compose、jq。# 拉取 fabric-samples切到需要的版本分支 git clone https://github.com/hyperledger/fabric-samples.git cd fabric-samples git checkout v2.2.12 # 拉取 Fabric 镜像与命令行工具 curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.2.12 1.5.9 # 启动测试网络创建名为 clinical 的通道 cd test-network ./network.sh up createChannel -c clinical -ca./network.sh up会拉起两个 peer 节点和一个 ordering 节点-ca参数会额外启动 Fabric CA 容器。-c clinical用于指定通道名后续所有链码部署和调用都要对齐这个名字。这一段跑完后用docker ps应该能看到至少 6 个容器在运行。有一个非常关键但不写在命令里的细节./network.sh up之后当前 shell 并不会自动获得操作身份你需要手动 source 环境变量文件。这也是第一次跑链码最常见的翻车点我会在避坑章节专门展开。3.2 把链码写成“索引 授权”而不是“病历本身”链码我选 Go 写用 Fabric 官方提供的contract-api接口。写链码的时候记住一条核心原则所有写入世界状态的数据要么是哈希要么是 ID要么是时间戳坚决不存放经加密的大段原文。下面是一段可以直接放进链码包record.go的核心代码package main import ( encoding/json fmt time github.com/hyperledger/fabric-contract-api-go/contractapi ) type MedicalContract struct { contractapi.Contract } type MedicalRecord struct { RecordID string json:recordId PatientID string json:patientId DoctorID string json:doctorId RecordHash string json:recordHash DataRef string json:dataRef CreatedAt int64 json:createdAt } func (c *MedicalContract) CreateRecord(ctx contractapi.TransactionContextInterface, recordID string, patientID string, doctorID string, recordHash string, dataRef string) error { exists, err : c.RecordExists(ctx, recordID) if err ! nil { return err } if exists { return fmt.Errorf(record %s already exists, recordID) } record : MedicalRecord{ RecordID: recordID, PatientID: patientID, DoctorID: doctorID, RecordHash: recordHash, DataRef: dataRef, CreatedAt: time.Now().Unix(), } recordBytes, _ : json.Marshal(record) return ctx.GetStub().PutState(recordID, recordBytes) } func (c *MedicalContract) RecordExists(ctx contractapi.TransactionContextInterface, recordID string) (bool, error) { recordBytes, err : ctx.GetStub().GetState(recordID) if err ! nil { return false, fmt.Errorf(failed to read state: %v, err) } return recordBytes ! nil, nil }这段代码的逻辑不复杂CreateRecord先查重再组装结构体最后PutState。注意Contract结构体的注册方式你的main函数里要调用contractapi.NewChaincode(MedicalContract{})再Start()这部分每个链码都一样不再贴出来。核心参数是RecordHash和DataRef调用者在传给链码之前就已经计算好了哈希。链码本身不承担任何加密计算它只做存证。这样设计有个好处将来换加密算法、换存储后端链码一行都不用改。3.3 背书策略和私有数据集合怎么一起传给 peer部署链码时要传两个配置背书策略和私有数据集合定义文件。先写一个collections_config.json用于把recordHash、dataRef这些字段限定在指定机构范围内[ { name: medicalPrivate, policy: OR(Org1MSP.member, Org2MSP.member), requiredPeerCount: 1, maxPeerCount: 2, blockToLive: 0 } ]requiredPeerCount表示背书阶段最少需要几个 peer 把私有数据存到本地私有状态库maxPeerCount是向其他授权节点分发私有数据的最大节点数。blockToLive设成 0 表示私有数据永不过期清理如果设为 3表示 3 个区块之后私有数据从节点上清除业务里只有哈希上链的存证场景不需要设这个值。链码部署命令如下重点看--collections-config参数export PATH${PWD}/../bin:$PATH export FABRIC_CFG_PATH${PWD}/../config export CORE_PEER_TLS_ENABLEDtrue export CORE_PEER_LOCALMSPIDOrg1MSP export CORE_PEER_TLS_ROOTCERT_FILE${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt export CORE_PEER_MSPCONFIGPATH${PWD}/organizations/peerOrganizations/org1.example.com/users/Adminorg1.example.com/msp export CORE_PEER_ADDRESSlocalhost:7051 peer lifecycle chaincode package medical.tar.gz \ --path ../medical-chaincode \ --lang golang \ --label medical_1.0 peer lifecycle chaincode install medical.tar.gz peer lifecycle chaincode approveformyorg -o localhost:7050 \ --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ --channelID clinical --name medical --version 1.0 \ --package-id medical_1.0:package-id \ --collections-config ../medical-chaincode/collections_config.json peer lifecycle chaincode commit -o localhost:7050 \ --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ --channelID clinical --name medical --version 1.0 \ --collections-config ../medical-chaincode/collections_config.json \ --peerAddresses localhost:7051 --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt这段环境变量是最容易出错的CORE_PEER_ADDRESS决定了你当前 shell 以哪个 peer 的身份操作。部署阶段用 Org1 身份安装、批准commit 阶段再带上 Org2 的peerAddresses才能让通道上的两个组织都认可这个链码。命令里的--package-id是安装后返回的一长串哈希必须先用peer lifecycle chaincode queryinstalled查出来再填进去。提示反复导出环境变量容易乱建议把上面这些 export 写成一个setenv.sh每次操作前 source 一下。我自己的实验环境里一定是先跑这个脚本再敲其他命令。4. 哈希指纹上链敏感文件走 IPFS加密与回填的完整链路4.1 客户端加密AES-GCM 的密钥、IV 与密文格式原文不能直接传给链码也不能直接扔到 IPFS。客户端先把整个 PDF 用 AES-256-GCM 加密密文才允许上传到公共存储网络。AES-GCM 属于带认证的加密加密后自动生成认证标签任何篡改都能被检测出来比老式的 AES-CBC 更适合“存证再验证”的场景。import os from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes def encrypt_file(raw_path: str, key: bytes, iv: bytes) - bytes: with open(raw_path, rb) as f: plaintext f.read() encryptor Cipher(algorithms.AES(key), modes.GCM(iv)).encryptor() ciphertext encryptor.update(plaintext) encryptor.finalize() return ciphertext, encryptor.tag # tag 就是认证标签代码里的iv是 96 位随机数也就是 12 个字节这是 GCM 模式推荐的固定长度tag是 16 字节的认证标签。密钥key由调用方生成长度 32 字节。这三个参数最终都要保存下来密钥存到 KMS 或服务器的环境变量IV 和 tag 可以跟着密文一起放到 IPFS 对象里。有一点容易绕进去GCM 的 IV 长度如果随便填 16 字节代码不会报错但安全性会降级。我第一次写这段就吃过亏直接把 16 字节当 IV 用检测工具直接给 warning。固定写成os.urandom(12)就好。4.2 上传 IPFS 拿 CID再把 CID 写进链码加密完成后把密文上传到本地 IPFS 节点。IPFS 官方提供了 HTTP API最简单的调用方式是curl但要注意 multipart 格式# 假设本地 IPFS 节点监听 5001 端口 curl -X POST -F fileencrypted_record.bin \ http://127.0.0.1:5001/api/v0/add?pintrue # 返回结果示例cid 字段就是文件指纹 # {Name:encrypted_record.bin,Hash:QmXo...,Size:12345}返回的Hash字段就是 CID它是内容的寻址地址文件内容一变CID 就变。把这个 CID 作为DataRef同时用原始 PDF 计算 SHA-256 摘要作为RecordHash再调用链码写入。这样一来区块链账本上没有任何明文健康信息却牢牢锚定了原文的完整性和存储位置。链码调用示例peer chaincode invoke -o localhost:7050 \ --tls --cafile ${PWD}/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ -C clinical -n medical \ -c {Args:[CreateRecord,rec-001,pat-1001,doc-2001,7d865e6e8b3e...,QmXo8...]} \ --peerAddresses localhost:7051 \ --tlsRootCertFiles ${PWD}/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt参数顺序必须和链码函数签名严格对齐recordID、patientID、doctorID、recordHash、dataRef。我犯过的错误是把 hash 和 dataRef 传反链码不报错但下载后校验永远失败。建议在链码里对这个字段值做一次长度预检比如要求recordHash必须是 64 位 hex 字符串提前拦截低级错误。4.3 评审必问的密钥管理怎么用三层式回答到了这一步系统已经能跑通“加密原文 → 存 IPFS → 哈希上链 → 授权查询”。但答辩时评审一定会追问一个问题“密钥存在哪服务器被攻破怎么办”毕设级别的实现我不会硬吹 KMS。实际做法是三层第一层密钥文件放后端服务独立目录权限设为 600只有服务进程可读第二层密钥在内存里加载后立刻把文件句柄关掉进程常驻期间不落盘第三层在论文中明确写清楚生产环境应当换用云 KMS 或硬件密码机毕设展示的是逻辑闭环。# 生成一份随机密钥并设置严格权限 openssl rand -base64 32 /opt/medical-service/keys/aes.key chmod 600 /opt/medical-service/keys/aes.key chown medical:medical /opt/medical-service/keys/aes.key这样回答的好处是显得你知道边界在哪里没有吹牛说自己做了企业级密钥管理但每一步都有可验证的落点。评审更想听到的是“明白生产差距并有替代方案”而不是“绝对安全”。5. 医疗记录链码最常见的 5 个翻车点与排查路径5.1 升级链码后查询返回空旧数据全“丢”现象链码 v1.0 已经写了几十条记录升级到 v1.1 后调用QueryRecord返回空数组但 peer 日志里没有任何报错。原因链码升级后如果新版本里修改了私有数据集合的定义或命名旧数据存在旧的 collection 名字下新代码读的是新 collection。普通PutState的数据丢失概率低但用GetPrivateData时非常容易踩。解决升级链码时保持collections_config.json里的集合名不变如果非要改名必须在链码里做数据迁移遍历旧键重新写入。毕设阶段最稳妥的做法是升级前先peer chaincode query备份状态改完再重新写入。5.2 背书策略报错endorsement policy failure现象invoke 时返回Error: endorsement failure during invoke没有更多细节。原因背书策略要求两个组织共同背书但命令里只传了 Org1 的--peerAddresses或者当前 shell 的CORE_PEER_LOCALMSPID是 Org1但背书策略写的是AND(Org2MSP.member)。还有一种常见情况--tlsRootCertFiles路径写错TLS 握手直接失败。解决把 invoke 命令的--peerAddresses和--tlsRootCertFiles都补全两个组织各传一次。同时用peer lifecycle chaincode querycommitted -C clinical -n medical查一下当前生效的背书策略和代码里的collections_config.json对齐。peer lifecycle chaincode querycommitted -C clinical -n medical --output json | jq5.3 peer 日志报 MSP 或 gRPC 连接错误现象启动后链码容器起来了但docker logs peer0.org1.example.com里反复出现failed to get MSP、connection refused这类日志invoke 超时。原因Fabric 镜像版本和 fabric-samples 分支不匹配。比如仓库 checkout 到main分支但安装脚本下载的是 2.2.12 镜像链码容器因为缺依赖直接 crashpeer 就报 gRPC 连接错误。解决统一版本。我一般会先git checkout v2.2.12再重新执行安装脚本指定完全相同的版本号。检查版本统一用一条命令docker images | grep hyperledger如果看到多个 fabric-peer 版本混在一起直接./network.sh down后重新 up。5.4 区块体积暴涨把 20MB 影像 base64 进了链现象插入一条包含胸片影像的记录后peer 所在磁盘空间迅速下降查询变慢。原因链码里把data字段映射成[]byte客户端直接传了一段完整的 base64 DICOM 文件。区块链本身吞吐就有限大块数据进区块会拖垮所有节点。解决链码彻底去掉存原文的字段。约定所有文件类数据只传 SHA-256 哈希和存储引用。我通常在CreateRecord函数开头加一个长度校验如果recordHash不是 64 位 hex直接拒绝交易。这样至少能挡住一半的误用。5.5 演示时网络起不来hosts 映射与容器残留现象答辩现场跑./network.sh up后 peer 容器一会儿就退出了报错说解析不到orderer.example.com或者端口被占用。原因Fabric 容器之间通过容器名通信但 SDK 和 CLI 从宿主机连接时靠 localhost 映射的宿主机端口。如果上次 down 的时候容器没有清干净7051端口被残留容器占用新的 peer 起不来另一种情况是换网络环境后/etc/hosts里残留旧的映射。解决演示前做一次彻底清理然后单命令拉起。./network.sh down docker system prune -a --volumes -f # 清理所有残留镜像和卷 ./network.sh up createChannel -c clinical -ca提示docker system prune -a会把无关镜像也清掉只建议在演示现场机器上执行自己开发机慎用。清完之后 IPFS 容器如果没写在同一个 compose 网络里也要重新启动。6. 从跑通到答辩五分钟演示验证与一句讲清架构6.1 给答辩准备的“一键重置”演示脚本答辩前一天我会把整条链路封装成一个脚本保证现场三分钟内从零跑通。脚本做的事按顺序是清理网络、启动网络、部署链码、加密一份测试病历、上传 IPFS、调用链码、然后执行验证查询。#!/bin/bash set -e cd ~/fabric-samples/test-network ./network.sh down ./network.sh up createChannel -c clinical -ca ./network.sh deployCC -ccn medical -ccp ../medical-chaincode -ccl go cd ~/medical-service python3 encrypt_and_upload.py --input demo.pdf --key keys/aes.key peer chaincode invoke -o localhost:7050 \ --tls --cafile organizations/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ -C clinical -n medical \ -c {Args:[CreateRecord,rec-demo,pat-demo,doc-demo,hash,cid]} \ --peerAddresses localhost:7051 \ --tlsRootCertFiles organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt脚本背后的encrypt_and_upload.py会打印出每个环节的产物加密后的密文大小、IPFS CID、SHA-256 哈希。这些都是答辩时展示“闭环”的硬材料。6.2 用 GetHistoryForKey 现场证明“不可篡改”Fabric 的链码接口提供了一个GetHistoryForKey它是答辩时的秘密武器。现场调用它能列出rec-demo这条记录每一次被修改的交易 ID、操作者和时间戳。这段代码加进链码的QueryHistory函数里func (c *MedicalContract) QueryHistory(ctx contractapi.TransactionContextInterface, recordID string) ([]interface{}, error) { historyIter, err : ctx.GetStub().GetHistoryForKey(recordID) if err ! nil { return nil, err } defer historyIter.Close() var history []interface{} for historyIter.HasNext() { entry, err : historyIter.Next() if err ! nil { return nil, err } history append(history, map[string]interface{}{ txId: entry.TxId, timestamp: entry.Timestamp, isDelete: entry.IsDelete, value: string(entry.Value), }) } return history, nil }演示时先把记录哈希改成一个错误值再查历史就能看到同一条recordId下出现两次交易评审一眼理解“为什么区块链更适合存证”。6.3 一句话版架构与三个必答问题答辩陈述我用一句话定框架一条联盟链、两张状态表、三段权限、四层存储——链上是索引、哈希和授权链下是加密原文、IPFS 文件与本地密钥。评审追问大概率集中在三个问题上为什么不用公链、密钥丢了怎么办、吞吐量行不行。回答口径分别是医疗数据需要准入与隐私隔离密钥由患者侧托管而非链上存储本系统定位存证而非高频交易性能瓶颈在存储层而不在链上。我一般会把重置脚本放在桌面上标题就叫one_key_demo.sh答辩当天先跑一次再进会场。这个习惯救了我两次一次是演示前发现 IPFS 容器没起另一次是链码包标签写错导致安装失败。技术方案做到最后拼的往往不是新框架而是这些看似不起眼的检查和预演。希望帮到你。本文还有配套的精品资源点击获取