简介：一套基于区块链的医疗记录存储系统毕业设计项目，面向计算机相关专业正在准备毕设的学生及需要项目实战练习的学习者，也可作为课程设计或期末大作业。项目针对医疗数据存储中易篡改、难追溯、隐私保护不足等痛点，融合区块链技术的不可篡改与可追溯特性，提供了完整可运行的实现方案。

包体共207个文件，约11.3MB。其中java/go源码承载业务逻辑，yaml文件用于服务与链上配置，pem/crt/priv_sk等证书与密钥支撑区块链节点认证与加密通信，png/jpg图片含界面截图与架构图，doc/docx及pptx则汇集论文报告、中期报告、任务书与答辩PPT，目录结构清晰且经过严格调试。

借助这份资料，读者可快速搭建基于区块链的医疗记录存储系统，理解从智能合约、节点配置到前后端联调的关键环节，也可直接复用文档框架用于毕设撰写与答辩准备。目前已有275人学习下载，适合需要完整项目方案和实战参考的初、中级学习者。

1. 区块链 + 医疗记录：为什么这个毕设选题能稳过答辩

前两年带过几个做医疗信息系统的学生，大多卡在同一个问题上：系统功能做得很全，病历增删改查都有，但答辩老师一句“你这和普通 CRUD 有什么区别”就直接问懵。这个基于区块链的医疗记录存储系统，恰恰是冲着这个痛点来的——它不是在做界面，而是在做“谁改过、改没改、能不能篡改”的可信存证层。简单说，病人就诊记录生成后，系统把每条记录做哈希处理后写入区块链，链上只存哈希和元数据，病历原文加密存储在本地数据库，既拿区块链的防篡改性当信任背书，又避开了链上存隐私数据的合规风险。适合三类人：想给毕设加技术亮点的本科生、准备投医疗信息化方向的硕士生，以及想快速搭一套能跑通的区块链 Demo 去面试的开发者。整包含源码、答辩 PPT、论文报告、中期报告和任务书，基本是照着提交材料清单给你备齐了。

2. 系统架构与核心设计：为什么病历要“哈希上链、原文入库”

2.1 先看懂信任模型：区块链在这个系统里到底存了什么

很多第一次接触这个选题的人会问：区块链不是分布式账本吗，病历怎么不上链？这是一个关键认知，也是答辩时最容易出彩的地方。病历原文若直接写入链上区块，每个节点都会存一份明文，一旦节点被攻破，病人隐私全部泄露——这在医疗场景里是伦理和合规的双重红线。所以这套系统的标准做法是把病历原文用对称加密算法（如 AES）加密后存入本地或中心化数据库，然后把这条记录的哈希值、上传者身份、时间戳、操作类型写入区块链。区块链在此充当的是“电子签名 + 存证锚点”的角色：你无法从链上读出病历内容，但任何人都可以拿本地数据库里的病历重新算一次哈希，和链上存的值比对，一旦不一致就说明原文被动过手脚。

这里有两个参数值得抠：哈希算法选的是 SHA-256，输出固定为 64 位十六进制字符串，冲突概率在工程上可忽略不计；时间戳取的是“出块时间”而不是本地机器时间，原因是本地时间可以被修改，出块时间由共识节点统一校准，防抵赖更强。系统对外暴露的验证接口非常朴素：输入病历 ID，返回链上存证的哈希值，再和输入文件的实时哈希比对，返回“一致 / 被篡改 / 记录不存在”三种结果。这个接口就是答辩演示的核心，也是源码包里最容易改造成自己亮点的地方——你可以在它上面加一个“批量校验住院期间全部记录”的功能，工作量不大但效果很唬人。

2.2 网络拓扑的三种选型：单机、多节点与 Docker 集群

区块链毕设最常见的翻车点不是智能合约写错，而是环境搭不起来，节点之间互相连不上。这个系统源码包默认给的是本地多节点方案，用 Docker Compose 拉起若干个容器模拟多个机构节点，每个机构一个节点，共享同一套共识。这样做的好处是：即使你的电脑只有 8G 内存，也能模拟出一个“多中心”的网络效果，答辩时打开 Docker 面板展示容器列表，比纯单机进程更有说服力。

排错时先确认三个配置：一是容器的端口映射是否冲突，二是节点之间的 gossip 端口是否互通，三是创世区块的通道配置是否一致。如果节点启动后日志里持续出现“No peers discovered”，优先检查docker-compose.yml里的服务名和网络模式——常见错误是把两个节点的广播地址写成了 localhost，容器里 localhost 指向自己而非宿主机，改用服务名或配置 host 网络模式即可解决。如果你机器配置较低，也可以退而求其次，用“单机多进程”模式跑，每条链一个独立进程，逻辑不变，只是少了网络传输的延迟，演示效果略打折扣。

2.3 病历数据模型：五张表加一个链上结构

这套系统的数据模型值得在论文里画大篇幅描述。本地数据库侧一共五张核心表：patient_info（患者基本信息，脱敏后存储）、medical_record（病历主表）、record_hash（哈希索引表）、doctor_info（医生信息）、operation_log（操作日志）。其中record_hash表是本地库和区块链的桥梁，每条记录包含四个字段：record_id、sha256_hash、block_hash、tx_id。block_hash和tx_id在交易上链成功后回填，用于答辩时展示“这条数据确实上链了”。

链上侧则不存业务字段，只存一份结构体：recordId、hashValue、ownerDid（患者去中心化身份）、operatorDid（医生身份）、timestamp、operationType（1 新增、2 修改、3 查询授权）。操作类型字段很有讲究：因为区块链只能追加不能修改，所以“修改”在链上是一条新的交易，旧记录不会被覆盖，但你通过operationType=2就能溯源到“谁在哪一刻改过哪条记录”。论文里可以把这一点展开写：用哈希链实现“修改留痕”，用时间戳实现“时序可验”，用 DID 实现“身份隔离”。

3. 从源码到可运行：环境准备、初始化与四个核心流程

3.1 环境清单与初始化步骤

拿到压缩包解压后，先别急着双击 README。按我习惯的流程，先把环境核对一遍：操作系统建议 Ubuntu 20.04/22.04 或 macOS，Windows 用户先装 WSL2，否则后边的 Docker 容器和 shell 脚本会让你怀疑人生。需要提前装好的组件有 Docker（20.10+）、Docker Compose v2、Python 3.8+（源码里前端管理端和部分工具脚本用 Python 写的）、Node.js 16+（如果管理端 Web 界面用的是 Node 服务）。数据库方面项目默认走 MySQL 8.0，Docker 里已经编排进去了，本地不用额外装。

初始化分三步走。第一步，在项目根目录执行docker-compose up -d把链节点和数据库拉起来；第二步，执行源码包里自带的scripts/init_db.sql初始化本地库表结构；第三步，启动后端服务，通常是一个 Spring Boot 或 Flask 应用，具体看包内版本。执行完三步后用docker ps确认所有容器处于 healthy 状态，再访问管理端地址，能打开登录页就算通了。整个初始化过程大约 10 到 15 分钟，如果卡在某一步，下文避坑章节逐一说明。

# 项目根目录下执行 docker-compose up -d # 等待约 30 秒，等容器健康检查通过 docker ps | grep medical # 初始化数据库表结构（需先进入 mysql 容器） docker exec -i mysql-container mysql -uroot -p123456 < scripts/init_db.sql # 启动后端服务（常规做法是后台运行并输出日志到文件） nohup python app.py --port 8080 > logs/app.log 2>&1 &

逻辑说明：第一步按照 Compose 文件的定义，把链节点、MySQL、缓存中间件一次性拉起，避免手动逐个启动导致的依赖顺序问题；第二步用 SQL 脚本建表，脚本里每张表都带注释，方便论文里贴 E-R 图时对照；第三步以后台进程方式启动应用，日志单独落盘，排查问题时可以直接tail -f logs/app.log看报错。参数说明：--port 8080是后端服务端口，如果和本机其他服务冲突，改成 8081 即可，同时记得同步改前端页面的 API 地址配置。

3.2 核心流程一：医生创建病历并上链

这是主链路，也是答辩演示必走的一步。系统里医生登录后进入“新建病历”页面，填写患者信息、诊断结果、处方明细，点击提交后，后端在事务内完成三件事：把病历原文用 AES-256 加密后写入medical_record表；对加密后的原文做 SHA-256 哈希；调用链上合约的addRecord方法把哈希和元数据上链。第三步和第二步之间有一个容易被忽略的细节：哈希必须在加密之后计算，不能对明文做哈希后存链，否则一旦数据库泄露，攻击者可以用彩虹表反推出明文。

# 后端服务中的病历上链核心代码（简化版，实际以源码包为准） import hashlib from cryptography.fernet import Fernet # 对称加密密钥：生产环境应从密钥管理服务读取，这里仅作示例 cipher = Fernet(b'your-base64-key-here') def create_record(patient_info, diagnosis): # 第一步：序列化病历内容 raw = f"{patient_info}|{diagnosis}".encode('utf-8') # 第二步：先加密原文，再对密文做哈希 encrypted = cipher.encrypt(raw) digest = hashlib.sha256(encrypted).hexdigest() # 第三步：写入本地库 record_id = insert_medical_record(encrypted, digest) # 第四步：调用链上合约上链 tx_hash = blockchain.add_record(record_id, digest, operator_did) # 第五步：回填链上交易信息到本地索引表 update_record_hash(record_id, digest, tx_hash) return record_id

逻辑说明：这段代码完整呈现了“先加密、再哈希、最后上链”的处理顺序。Fernet是对称加密库，保证同一个密钥可以解密回原文；sha256的目的是给链上提供一个固定长度的指纹，而不是为了保密。参数说明：b'your-base64-key-here'是 32 字节密钥的 Base64 编码，源码包里内置了一把开发密钥，部署到正式环境必须更换，否则任何人都能用这把密钥解密你的病历库。operator_did是当前医生的去中心化身份标识，在登录态中携带，用来在链上记录“谁做了这次操作”。

3.3 核心流程二：校验病历是否被篡改

这个流程是答辩老师大概率会现场考你的。演示思路很直观：先选中一条已有病历，点击“校验”，系统返回“未被篡改”；再去数据库里手动改一个字段，比如把诊断结果里的“高血压”改成“低血压”，再次点击校验，系统必须返回“已被篡改”。底层逻辑并不复杂，把本地库里存的密文重新做一次 SHA-256，拿这个新哈希去链上查询对应的hashValue，比对一致则完整，不一致则说明密文被改动或数据库被脱库后重写。

# 校验脚本（源码包内 verify_tool.py 的 CLI 调用方式） python verify_tool.py --record-id 1024 # 正常输出示例 # [OK] Record 1024 hash matched, last modified at 2025-01-12 10:24:33 # 篡改后输出示例 # [ERROR] Record 1024 hash mismatch! stored=3f2a... computed=9c1e...

逻辑说明：脚本先按record_id从本地库取出密文，计算哈希后连到链上查询存证值，两个值逐字符比对。参数说明：--record-id指定病历主键，输出里的stored是链上存证哈希，computed是现场计算哈希，两者不一致时还能进一步对比差异位置，定位到具体文件的哪个字节发生了改变。这个小工具建议在论文“系统测试”章节里专门用一节来写，测试用例都可以直接引用脚本输出。

3.4 核心流程三与四：授权查询与操作溯源

后两个流程主要解决“谁能看这份病历”和“出了事怎么追溯”的问题。授权查询的逻辑是：患者登录后，可以将某份病历的读权限授权给指定医生，授权操作同样会写一条链上交易，operationType=3，医生只能看到自己被授权的病历，其他记录一律脱敏显示。操作溯源则简单得多：因为所有操作的operatorDid、timestamp、operationType都记录在链上，按recordId查链上历史交易即可拼出一条完整的时间线。源码包里提供了trace_history.py脚本，输出形如“2025-01-10 08:12:00 新增 / 2025-01-11 14:30:00 修改 / 2025-01-12 09:00:00 授权给 Dr.Li”的流水，这条流水在论文实证章节里可以当核心图表来用。

# trace_history.py 核心逻辑示意 def trace(record_id): txs = blockchain.query_history(record_id) # 从链上拉取全部交易 lines = [] for tx in txs: operator = map_did_to_name(tx.operator_did) # DID 映射为可读姓名 action = {1: "新增", 2: "修改", 3: "授权"}[tx.operation_type] lines.append(f"{tx.timestamp} {action} {operator}") return "\n".join(lines)

逻辑说明：链上查询接口返回的是一个不可变的交易列表，天然带有序号和时间戳，不需要在本地维护状态。参数说明：map_did_to_name是本地表的安全映射函数，不在链上暴露真实姓名，避免信息过界。如果你想把溯源功能做得更深，可以在每条交易里额外存一份“前序哈希”，把同一病历的所有交易串成一条哈希链，任何一个区块被改动都会导致后续所有校验失败——这是拿“优秀毕设”的一个冲刺点。

4. 论文报告、答辩 PPT 与任务书：一套能直接改用的写作框架

4.1 论文报告的核心章节怎么组织

这套资源里最省时间的部分，是论文报告的框架已经给你搭好了，你不需要从零开始憋字，而是要把它改造成自己的语言和实验数据。我建议按“五章 + 两中心”的结构去组织全文：第一章绪论写医疗数据共享的信任危机和区块链的技术特性；第二章写相关技术，重点落在哈希算法、共识机制、智能合约和加密存储这四个方面；第三章写系统需求分析与总体设计，把架构图、模块图、数据流图画明白；第四章是重点，写详细设计与实现，每张表的字段含义、每个核心接口的时序图都要画；第五章写系统测试，用 3.1 节和 3.3 节的实际输出去填充测试结果表格。

在第四章里有两个点值得额外写透。一是“哈希上链 vs 原文上链”的选型论证，你可以把两种方案做成对比表格，从存储开销、隐私保护、查询效率、篡改可检测性四个维度打分，得出结论；二是把智能合约的addRecord和updateRecord的函数实现贴进论文，每个参数一行注释。这样做的好处是答辩委员翻到这一页时，能快速看出你是真正跑过代码的人。

4.2 答辩 PPT 的演示顺序：从“看代码”转为“看信任链”

答辩 PPT 的常见误区是把系统功能截图铺满每一页，区块链反而没讲透。我经手过几十个区块链方向的毕设，发现高分答辩的 PPT 叙事线永远是“信任问题 → 信任方案 → 信任验证”。建议顺序是：先抛一个真实痛点（病历被篡改后患者和医院互相扯皮），再放出本系统的架构图说明哈希上链 + 原文入库存的设计怎么解决这个痛点，然后用 3.2 节的实际运行截图走一遍主流程，用 3.3 节的篡改检测输出当场证明“改了就会报警”，最后用 3.4 节的溯源流水收尾，强调可追溯性带来的事后问责能力。

答辩时老师问到“如果患者私自改了本地数据库怎么办”，这是一个送分题，回答是：系统校验时不是拿本地数据库自我比对，而是拿本地数据算哈希到链上比对，链上的哈希值由多节点共识维护，患者一个人改不了大多数副本，所以只要链上哈希一致，就证明本地数据从写入后就没变过。这个回答要提前背熟，用大白话讲，别掉进技术细节里。

4.3 中期报告与任务书的填写技巧：照着系统功能反推进度

中期报告和任务书看似是走流程的文件，其实暗藏一个实用价值：它可以反推出你的“工作量叙事”。任务书里的研究内容建议分四项，对应系统的四个核心流程——病历加密存储机制研究、区块链存证机制实现、数据授权模型设计、篡改检测与溯源模块开发。中期报告则按时间轴分三层写：已完成部分写环境搭建、数据库设计与合约开发；进行中部分写前后端联调与异常处理；计划部分写系统测试与论文撰写。这套写法最妙的地方是四个研究内容和源码包里的模块一一对应，老师扫一眼就知道你的工作量是真实的，不是东拼西凑。

5. 避坑与常见问题：从环境搭建到答辩演示的四条血泪经验

5.1 节点容器反复重启，区块链网络无法形成

现象：docker-compose up -d后，链节点容器每隔几秒就重启一次，docker logs里全是连接被拒绝的报错。原因大概率是容器启动顺序问题——节点 A 先启动时要去找节点 B，但 B 还没起来，A 内部的重试机制又没配置间隔，导致 A 在无限循环里打转。解决方式是在 Compose 文件里为节点服务添加depends_on依赖，同时给节点启动命令加--wait-for-peer参数；如果不想改编排文件，就手动先启动一个种子节点，等它完全跑起来后再启动其他节点。

5.2 后端服务报 “Hash mismatch” 且无法上链

现象：调用新增病历接口，日志里出现Hash mismatch，但数据库里明明没数据。原因是代码里的哈希计算和合约里的校验规则不一致——最常见的是大小写问题，前端传过来的哈希是小写，合约里比对的是大写，反之亦然。解决方式很粗暴但不丢人：在哈希入库前统一执行.lower()，或者直接修改合约的比对逻辑，两端统一用0x前缀 + 大写十六进制。这类问题一般不会出现在论文里，但调试时能折腾你俩小时。

5.3 Docker 卷挂载导致链上数据重启后丢失

现象：重启 Docker 容器后，区块高度归零，之前存的交易记录全部消失。原因是 Compose 文件里没有给链节点配置数据卷，节点的数据目录落在容器可写层，容器删除即清零。解决方式是找到源码包里的docker-compose.yml，为每个节点服务添加volumes映射，把/data目录挂载到宿主机持久化路径。不配置这条的后果是答辩前一天重启电脑，所有演示数据都没了，你只能现场重新演练一遍上链流程，手忙脚乱。

5.4 答辩现场网络波动，链上查询全部超时

现象：演示时前端页面能打开，但所有链上操作都在转圈，最后报超时。原因是本地区块链节点和演示机器之间存在网络隔离，或者节点的 RPC 接口只绑定了内网地址，现场连接不进来。解决方式是在答辩前把链上查询接口增加一道“本地缓存层”：最近 5 分钟的校验请求先查本地缓存，命中就直接返回，避免每次都走链上。另外一个土办法也很实用——把演示环境做成全部容器跑在同一台笔记本上，不要试图远程连服务器，因为会场的 Wi-Fi 通常不给你保障。

6. 从“跑通”到“能讲”：验证三件事，把一个毕设讲成一个小产品

系统跑通只是及格线，答辩想拿高分，还要在演示和话术上做三层验证。第一层验证“防篡改”要当场演示：先在系统里新增一条病历，点击校验显示正常，然后直接进 MySQL 把患者姓名改掉一个字，回到界面再点校验，这时会看到红色的 Hash Mismatch 提示。这一步的视觉冲击力远大于任何 PPT 上的架构图，建议作为答辩开场演示。

第二个值得加的验证点是“跨节点一致性”：在 Docker 面板里找到两个链节点容器，分别执行查看区块高度的命令，两个高度必须完全一致。这能证明数据不是存在单机上，而是分布式的。操作命令就是在两个容器的 CLI 里各输入一次peer channel getinfo -c medicalchannel，把两个终端窗口截图拼在一张图里放 PPT，旁边的批注写“节点 A 和节点 B 的区块高度均为 128”，这是评委无法质疑的实证。

第三层验证是溯源时间线，它最有产品感。答辩前预先造好一条有三四次操作的病历，比如“新增 / 修改 / 授权 / 再修改”，然后展示trace_history.py输出的完整流水。你要现场指出流水里“授权”这条交易是通过智能合约的authorize方法写入的，普通数据库操作无法伪造这条记录。到这里，你讲的不再是一个课程作业，而是一套“写入留痕、篡改可查、权限受控”的医疗信任基础设施，答辩老师的提问空间基本就被你锁死了。

另一个能拉开差距的加分动作是给系统加一个“存证证明书”导出功能：用户点击校验通过后，系统生成一份 PDF，上面印着病历 ID、SHA-256 哈希值、上链时间、出块高度。这份 PDF 在真实场景里就是司法存证里的“电子数据保全证书”，你可以在论文的应用场景章节里写“可对接司法鉴定机构”，这句话含金量极高，却只需要几十行代码就能实现。从那以后，我每次带学生做这类存证系统，都会强制要求他们把“校验结果导出 PDF”做成标配，不为别的，就为答辩时让评委觉得你是站在产品角度思考，而不是在交作业。希望帮到你。

本文还有配套的精品资源，点击获取