简介一份基于Hyperledger Fabric区块链的工作流审批应用毕业设计项目面向软件工程、计科、人工智能等计算机相关专业的学生与开发者既可作为毕设、课设的完整参考也可用于区块链入门实践。项目利用Fabric搭建联盟链网络实现审批流程上链与自动化执行代码经过测试运行成功功能可用。压缩包共163个文件整体仅224KB核心以pem/crt证书、key私钥等链上身份材料为主配合js链码业务逻辑、json前端交互与配置、yaml/sh环境脚本、pug/html页面模板完整覆盖区块链应用的各层结构多个sk文件则对应不同组织或节点的身份密钥展示Fabric多组织网络的证书体系。内容包含可直接运行的源码、详细设计文档及全部配套资料便于在此代码基础上二次开发如调整审批规则、扩展业务模块同时对通道创建、链码部署、身份认证等关键环节也有演示价值。已有582人学习下载对准备区块链方向毕业设计或课程设计的人来说是高性价比参考资源。1. 基于 hyperledger fabric 区块链的工作流审批这份毕设源码能改出什么很多人冲着“hyperledger fabric 区块链工作流审批应用”这套毕设源码来第一反应是问它到底能不能直接跑起来。我的回答是能但前提是你先搞懂解压包里那一长串_sk私钥文件是干什么用的。这套基于 Hyperledger Fabric 的工作流审批项目不是把审批单简单存进数据库而是把“提交—审批—驳回”的每一步都写成链上交易区块一旦生成就改不了天然适合请假、报销、用章这类需要留痕的企业审批场景。它适合两类人一类是计算机相关专业拿它做毕设、课设答辩的学生另一类是想快速体验 Fabric 2.x 从网络搭建到应用联调全过程的开发者。源码、详细文档、网络证书材料一次带齐按文档跑通后你能亲眼看到一条审批链路在链上逐块确认这在答辩时是非常加分的实物演示。2. 网络与证书先行从 configtx 到 _sk 私钥的搭建四步2.1 联盟链凭什么适合审批Fabric 的四个关键设计先解决一个选型问题为什么是 Hyperledger Fabric而不是以太坊或者其他联盟链框架工作流审批有几个硬性要求参与方员工、部门主管、财务、审计彼此信任但又不是完全信任审批数据不能公开给链外无关人员系统需要支持事后审计和追溯写入性能要能撑住企业内部日常请求量。Fabric 的四个设计恰好对上。第一它是联盟链有准入机制。所有节点和用户都通过 MSPMembership Service Provider管理身份私钥文件就是身份的凭证。第二通道Channel机制可以把不同部门的交易隔离在不同的链上比如财务审批通道和人事审批通道互不可见。第三它的背书-排序-验证三段式流程把“谁同意这笔交易”和“交易按什么顺序打包”彻底分开背书策略可以精确到某个组织甚至某个角色。第四链码运行在 Docker 容器里支持 Go、Node.js、Java开发门槛比 Solidity 低不少对毕设团队来说这意味着后端同学能快速上手。下表是这份资源里最核心的几个组件解压后你会在 docker-compose 文件和配置目录里一一对应到它们组件在资源中的角色关键配置Peer 节点维护账本副本执行链码core.yamlMSP 路径Orderer 节点对交易排序并打包成区块configtx.yaml 中的共识配置CA可选签发证书生产环境使用fabric-ca-server-config.yamlCLI 容器执行 peer 命令完成通道和链码操作挂载 crypto-config 与 channel-artifactsCouchDB状态数据库支持富查询couchdb 容器及索引定义我一般拿到任何 Fabric 项目第一件事不是看业务代码而是打开crypto-config.yaml和configtx.yaml把组织、节点、用户的关系理清楚。这两个文件决定了整条链的骨架后续所有排错都跟它们有关。2.2 crypto-config 与 configtx证书、通道和组织怎么定义这份资源解压后你会看到大量以_sk结尾的文件比如0d46ccf0e9436c1bc3b6e2bf80cdb202c4943604f95c72ee0ff839d3ec300719_sk。这是 Fabric 默认生成的 ECDSA 私钥文件文件名是私钥的 SKISubject Key Identifier经过 SHA-256 哈希后的十六进制串私钥内容用 PEM 格式编码。旁边通常还有同名的-cert.pem证书文件。它们共同构成某个组织下管理员或用户的 MSP 身份目录_sk负责签名证书负责让别人验证你的签名。这些文件不是手工生成的而是由cryptogen工具根据模板批量生成。典型的生成命令长这样# 在项目根目录执行生成全部组织的证书和私钥 cryptogen generate --config./crypto-config.yaml --output./crypto-config # 生成创世区块和通道配置文件 mkdir channel-artifacts configtxgen -profile TwoOrgsOrdererGenesis -channelID syschannel \ -outputBlock ./channel-artifacts/genesis.block configtxgen -profile OneOrgChannel -channelID mychannel \ -outputCreateChannelTx ./channel-artifacts/channel.tx # 生成锚节点更新交易org1 和 org2 各一份 configtxgen -profile OneOrgChannel -channelID mychannel \ -asOrg Org1MSP -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx逻辑说明第一条命令把所有组织的节点证书、管理员证书、TLS 证书全部生成到crypto-config目录生成后_sk私钥的路径结构是crypto-config/peerOrganizations/org1.example.com/users/Adminorg1.example.com/msp/keystore/。第二、三条命令生成排序服务和业务通道的初始配置channelID是通道名后面 CLI 加入通道时必须保持一致。第四条命令生成锚节点更新交易锚节点是组织间 gossip 同步数据的入口。参数说明-profile对应configtx.yaml里定义的 Profile 名称-channelID syschannel是排序服务的系统通道业务通道一般叫mychannel-asOrg指定当前交易归属于哪个 MSP。如果你发现生成的证书数量和资源文档里写的不一致多半是crypto-config.yaml里的Count字段填错了。2.3 容器化启动顺序orderer、peer 与 CLI 的配合证书和配置就绪后才是启动顺序的问题。常见错误是把所有容器一把梭docker-compose up -d然后发现 peer 连不上 orderer。正确顺序是先确认排序服务健康再启动 peer最后用 CLI 创建通道并把 peer 加进去。启动编排里有两个关键点。一个是挂载路径必须指向crypto-config和channel-artifacts目录另一个是环境变量里的CORE_PEER_MSPCONFIGPATH和CORE_PEER_LOCALMSPID要跟组织名严格对应。看一下典型的服务片段peer0.org1.example.com: container_name: peer0.org1.example.com image: hyperledger/fabric-peer:2.x # 以资源包里锁定的版本为准 environment: - CORE_PEER_IDpeer0.org1.example.com - CORE_PEER_LOCALMSPIDOrg1MSP - CORE_PEER_MSPCONFIGPATH/etc/hyperledger/fabric/msp - CORE_PEER_ADDRESSpeer0.org1.example.com:7051 volumes: - ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com:/etc/hyperledger/fabric - ./crypto-config/peerOrganizations/org1.example.com/users/Adminorg1.example.com:/etc/hyperledger/fabric/user逻辑说明CORE_PEER_LOCALMSPID告诉 peer 它属于哪个组织CORE_PEER_MSPCONFIGPATH指向容器内的 MSP 目录这两个值必须与configtx.yaml里的组织定义匹配否则启动时直接报 “msp is not defined”。volume 挂载时我习惯把整个 peer 组织目录挂进去而不是只挂单个证书文件这样可以避免文件权限问题。容器起来后进入 CLI 容器执行通道操作# 创建通道 peer channel create -o orderer.example.com:7050 -c mychannel \ -f ./channel-artifacts/channel.tx \ --tls --cafile /opt/home/managedtls/tlsca.example.com-cert.pem # 加入通道 peer channel join -b mychannel.block # 更新锚节点 peer channel update -o orderer.example.com:7050 -c mychannel \ -f ./channel-artifacts/Org1MSPanchors.tx \ --tls --cafile /opt/home/managedtls/tlsca.example.com-cert.pem参数说明-c是通道名必须与configtxgen生成channel.tx时的-channelID一致--cafile指向 orderer 的 TLS CA 证书关闭 TLS 时可以省略但不建议peer channel join -b接收的是上一步 create 命令生成的文件所以 create 和 join 必须按顺序执行。这套流程跑通后网络底层的骨架就算立住了。注意1.4 老版本用peer chaincode instantiate实例化链码2.x 改成 install approve commit 三件套。如果你手上的资源文档还在讲 instantiate说明它是老版本写法命令要按新版调整。3. 链码层的工作流引擎数据模型、状态机与背书策略3.1 审批单的链上模型一条记录如何表达“流转中”区块链上存数据核心问题是“怎么用有限字段表达一个会变化状态的对象”。工作流审批单不能只存一个status字段因为审批是分步骤的每一步由谁处理、意见是什么、时间戳是多少都要记录否则审计的时候说服不了人。我把这套资源的链码数据模型拆成三层单据主信息、步骤状态、历史明细。主信息包括单据编号、申请人、审批类型、金额、当前步骤步骤状态是一个结构体数组每个元素记录审批人、动作、意见和时间历史明细则依靠 Fabric 自带的键历史机制不做额外存储。下面是一个典型的 Go 链码数据模型type ApprovalRecord struct { RecordID string json:recordId // 单据编号同时用作账本键 Applicant string json:applicant // 申请人 ApproveType string json:approveType // 审批类型leave/payment/seal Amount int json:amount // 涉及金额 Status string json:status // PENDING/APPROVED/REJECTED CurrentStep int json:currentStep // 当前进行到第几步 Steps []ApproveStep json:steps // 每个审批节点的信息 CreateTime string json:createTime UpdateTime string json:updateTime } type ApproveStep struct { StepID int json:stepId Approver string json:approver // 审批人标识 Action string json:action // APPROVE/REJECT Comment string json:comment // 审批意见 Time string json:time }逻辑说明RecordID同时作为账本的 key查询时不需要额外遍历Steps数组的长度就是审批环节的总数CurrentStep指向当前应该由谁来处理。状态流转的判断全部围绕这两个字段展开。参数说明Amount用 int 而不是 float避免精度问题ApproveType用固定枚举字符串不要用中文直存排序和索引会省很多事。这套模型支持一级审批也支持多级审批只需要把Steps数组加长。3.2 状态机函数提交、审批、驳回的边界校验数据模型定了接下来是状态机。工作流最怕的是“乱流”同一张单被重复审批、申请人自己审批自己的单、已驳回的单又被改成通过。这些场景必须在链码里做硬校验不能只靠前端按钮控制。我按“谁在什么状态下能做什么操作”来写约束只有申请人能提交只有当前步骤指定的审批人能操作已终态APPROVED 或 REJECTED的单不允许再改每一步操作前都读取最新状态防止并发覆盖。func (s *SmartContract) SubmitApplication(ctx contractapi.TransactionContextInterface, recordID string, applicant string, approveType string, amount int, approvers []string) error { exists, err : s.RecordExists(ctx, recordID) if err ! nil { return err } if exists { return fmt.Errorf(record %s already exists, recordID) } var steps []ApproveStep for i, approver : range approvers { steps append(steps, ApproveStep{ StepID: i 1, Approver: approver, Action: PENDING, }) } record : ApprovalRecord{ RecordID: recordID, Applicant: applicant, ApproveType: approveType, Amount: amount, Status: PENDING, CurrentStep: 1, Steps: steps, CreateTime: time.Now().Format(time.RFC3339), } return s.PutState(recordID, record) }提交函数的核心是把审批步骤数组一次性写入账本CurrentStep初始为 1代表等待第一个审批人处理。这里没有校验approver是否真实存在于组织内严格的系统应该在链码里调用身份查询接口做二次确认。func (s *SmartContract) Approve(ctx contractapi.TransactionContextInterface, recordID string, comment string) error { recordJSON, err : s.GetState(recordID) if err ! nil { return err } if recordJSON nil { return fmt.Errorf(record not found) } var record ApprovalRecord json.Unmarshal(recordJSON, record) // 终态不允许操作 if record.Status APPROVED || record.Status REJECTED { return fmt.Errorf(record is already in final state) } // 从交易上下文里取调用者身份 clientID, err : ctx.GetClientIdentity().GetID() if err ! nil { return err } step : record.Steps[record.CurrentStep-1] if step.Approver ! clientID { return fmt.Errorf(only current step approver can operate) } if step.Action ! PENDING { return fmt.Errorf(current step already processed) } step.Action APPROVED step.Comment comment step.Time time.Now().Format(time.RFC3339) if record.CurrentStep len(record.Steps) { record.Status APPROVED } else { record.CurrentStep } record.UpdateTime time.Now().Format(time.RFC3339) return s.PutState(recordID, record) }逻辑说明ctx.GetClientIdentity().GetID()拿到的是调用链码时提交者证书的标识通常形如x509::CN...。这和数据库系统里current_user的概念类似但它是依托数字证书的伪造不了。用证书身份去和Steps里预设的审批人对上才能放行。参数说明comment审批意见在真实系统里可能涉及敏感信息如果不想让通道内所有成员都看到需要配私有数据集合这块放到下一节讲。CurrentStep的写法意味着这是一个顺序审批流如果要支持会签多人同时审模型要改成按StepID分组、组内独立判断。3.3 背书策略与私有数据多组织签名下的权限细节链码部署的最后一步是 commitcommit 之前要指定背书策略。很多毕设直接用了默认策略所有成员都能背书这在演示环境没问题但答辩时一旦被问到“如果财务组织不想让普通员工参与背书怎么办”就答不上来了。常见做法是在链码打包时显式声明背书策略{ channel: mychannel, chaincode: approval, endorsementPolicy: { identities: [ { name: Org1MSP, role: { name: member, mspId: Org1MSP } }, { name: Org2MSP, role: { name: member, mspId: Org2MSP } } ], policy: { 1-of: [ { signed-by: 0 }, { signed-by: 1 } ] } } }逻辑说明1-of表示任一组织背书即可2-of表示两个组织都要签名。审批场景建议至少1-of或AND(Org1MSP.member, Org2MSP.member)避免单组织作恶。背书结果会影响链码执行时的世界状态版本判断如果背书策略配置不一致同一通道上的多个 peer 可能对同一笔交易给出不同结果导致提交失败。如果审批意见里带有薪资、病例这类敏感数据我建议加上私有数据集合Private Data Collection。私有数据不上链只有授权组织能通过链码查询链上只存哈希。定义方式是在链码目录下放collections_config.json[ { name: approvalComments, policy: OR(Org1MSP.member,Org2MSP.member), requiredPeerCount: 1, maxPeerCount: 2, blockToLive: 0 } ]参数说明blockToLive设为 0 表示永不过期存量数据不会被自动清理requiredPeerCount表示至少几个 peer 需要保存私有数据policy控制谁能访问这份私有数据。在链码里用GetPrivateData和PutPrivateData替代普通的GetState/PutState。提示这套资源默认可能没启用私有数据集合聊胜于无建议把上一节ApproveStep.Comment字段用私有数据存储这样既保留完整审批记录又不让无关组织看到意见详情。4. 应用层打通REST 网关、审批页面与一键部署4.1 用 fabric-gateway 封装 REST 接口连接、提交与查询的分离链码写好后业务系统不能直接用 SDK 操作账本否则每个前端页面都要关心通道和证书细节。我把应用层拆成两层一层用 fabric-gateway 做链码调用另一层封装成 REST 接口给前端。调用链码时连接配置从connection-org1.yaml读取钱包里的身份从wallet目录加载。const { Gateway, Wallets } require(fabric-network); const path require(path); const fs require(fs); async function submitApply(recordId, applicant, type, amount, approvers) { const ccpPath path.resolve(__dirname, config, connection-org1.yaml); const ccp YAML.parse(fs.readFileSync(ccpPath, utf8)); const wallet await Wallets.newFileSystemWallet(path.resolve(__dirname, wallet)); const gateway new Gateway(); await gateway.connect(ccp, { wallet, identity: appUser, discovery: { enabled: true, asLocalhost: true } }); const network await gateway.getNetwork(mychannel); const contract network.getContract(approval); await contract.submitTransaction(SubmitApplication, recordId, applicant, type, amount.toString(), JSON.stringify(approvers)); await gateway.disconnect(); return { code: 0, message: 提交成功 }; }逻辑说明Wallets.newFileSystemWallet从本地钱包目录读取注册好的用户身份这个身份必须先通过 CA 注册并登记到钱包里否则连接会报Identity not found。submitTransaction会走完整的背书、排序、提交流程返回结果只有在交易上链后才拿到查询则用evaluateTransaction它只在单个 peer 上执行不产生新交易速度更快。参数说明discovery.enabled在开发环境配合asLocalhost: true使用生产环境改成 false 并显式指定 peer 地址。链码参数一律传字符串所以amount要.toString()approvers数组要JSON.stringify这个转换漏了会直接报参数个数不匹配。REST 层我习惯用 Express 把每个链码函数包成一个 POST 接口# 示例路由定义 POST /api/approval/submit POST /api/approval/approve POST /api/approval/reject GET /api/approval/list?applicantxxx GET /api/approval/detail/:recordId查询接口在写之前先确认链码里有对应的富查询函数。Fabric 默认只支持按键查询要做条件过滤必须在链码里用GetQueryResult配 CouchDB 索引否则一查全量数据性能很快崩。4.2 审批页面的交互流列表、详情与操作按钮的状态控制前端这部分毕设里最常见的是 Vue Element UI 组合。页面本身不复杂难点在于按钮的可用状态必须和链上状态严格对应待审的单显示“通过/驳回”已终态的单只显示详情。如果前端没有状态映射会出现审批人反复点击按钮、提交一堆无效交易的尴尬情况。我建议在列表页一次性把状态和当前步骤拉下来前端做状态机映射。核心逻辑大致是这样function getButtonStatus(record) { // 终态不可操作 if (record.Status APPROVED) return { approve: false, reject: false }; if (record.Status REJECTED) return { approve: false, reject: false }; // 待审状态仅当前步骤审批人可操作 const currentStep record.Steps[record.CurrentStep - 1]; if (currentStep currentStep.Approver currentUser) { return { approve: true, reject: true }; } return { approve: false, reject: false }; }逻辑说明currentUser来自前端登录态它必须对应链码里GetClientIdentity().GetID()返回的身份标识如果两边对不上会出现“按钮亮着但链码报无权限”的割裂。最稳妥的做法是后端在返回列表时就把canApprove字段算好前端只做展示不要在前端重复做权限判断。参数说明CurrentStep - 1是因为数组下标从 0 开始而业务步骤从 1 开始这个偏移最容易写漏。前端拿到记录后审批按钮的点击事件里要加重复提交锁防止用户双击产生两笔一模一样的交易。4.3 docker-compose 整包拉起从清理环境到业务可用的脚本顺序整套环境的部署脚本是所有 Fabric 项目里最容易让新手翻车的地方。我不建议直接用docker-compose up -d正确姿势是先把可能残留的容器和卷清理干净再按顺序启动。下面的命令序列基本覆盖了从零到业务可用的全过程# 1. 清理旧环境重要Fabric 容器和卷不清理会造成配置残留 docker-compose down -v rm -rf crypto-config channel-artifacts wallet # 2. 重新生成证书、创世块和通道文件对应 2.2 节的命令 bash scripts/generate.sh # 3. 启动基础网络 docker-compose up -d orderer.example.com \ peer0.org1.example.com peer0.org2.example.com \ couchdb0 couchdb1 cli # 4. 创建通道并让两台 peer 加入 docker exec cli peer channel create -c mychannel -f channel-artifacts/channel.tx docker exec cli peer channel join -b mychannel.block # 5. 安装、审批并提交链码Fabric 2.x 生命周期 docker exec cli peer lifecycle chaincode package approval.tar.gz \ --path /opt/gopath/src/github.com/approval \ --lang golang --label approval_1.0 docker exec cli peer lifecycle chaincode install approval.tar.gz docker exec cli peer lifecycle chaincode approveformyorg ... docker exec cli peer lifecycle chaincode commit ... # 6. 注册应用身份并启动后端 node scripts/registerUser.js appUser npm start逻辑说明第 1 步的down -v很重要不清卷的话CouchDB 里的旧数据会和新建的通道冲突表现是 peer 启动正常但查询全是旧数据。第 5 步的approveformyorg和commit需要传入包 ID包 ID 由install命令返回两条命令的包 ID 不一致就会 commit 超时。参数说明--path指向链码源码在容器内的挂载路径要和 docker-compose 里 cli 容器的 volume 映射一致--label是链码标识升级时改成approval_2.0之类的增量编号。整套脚本跑完用docker ps确认所有容器都处于Up状态再用后端接口打一笔测试单。注意脚本里-v删除的是命名卷不是源码目录。如果你把 crypto-config 也放在项目根目录rm -rf crypto-config会删掉证书下次生成前确认脚本路径正确。5. Fabric 踩坑清单证书、链码与 CouchDB 的高频翻车点5.1 peer 反复重启日志指向配置文件版本不一致现象docker-compose up后 peer 容器一直在重启docker logs里出现类似Error loading config: configtx.yaml: invalid configuration或unable to load channel config的报错。原因这通常不是代码问题而是 peer 容器加载的core.yaml、configtx.yaml与创世区块的通道配置不是同一套文件。常见于从别处拷贝项目后configtx 改过组织名但创世区块还是旧 Profile 生成的。Fabric 对配置一致性极敏感只要CORE_PEER_LOCALMSPID与创世块里的 MSP ID 对不上启动就失败。解决把channel-artifacts整个目录删掉重新生成同时确认configtx.yaml里的Organizations段和docker-compose里的环境变量完全一致。我习惯在generate.sh里加一条sha256sum genesis.block下次对比文件是否真的重新生成了。5.2 私钥 _sk 处理不当TLS 握手失败与 MSP 校验报错现象节点之间通信报client TLS handshake failed或者应用连接时报failed to load private key。原因_sk私钥文件在解压或传输过程中权限被改掉或者被复制到了错误目录。Fabric 对私钥文件权限有要求通常需要-rw-------权限权限过宽 CLI 会拒绝加载。另一个翻车点是挂载时只挂载了msp/keystore单目录导致 TLS 通信用不到对应的 CA 证书。解决把整个crypto-config目录挂载进容器不要在宿主机上随意挪动_sk文件。在生成脚本后面加一句find crypto-config -name *_sk -exec chmod 600 {} \;强制统一权限。如果应用层用钱包方式连接注册用户时对应的私钥也会出现在钱包目录里这个目录同样不能被 git 提交或随意共享。5.3 链码安装成功但 commit 超时definition not agreed现象peer lifecycle chaincode install返回成功但approveformyorg和commit报chaincode definition not agreed to by this org或直接超时。原因Fabric 2.x 的链码生命周期要求通道内每个组织的管理员分别 approve 同一份链码定义包括链码名称、版本、包 ID、背书策略。最常见的情况是两个组织 approve 时用的--package-id不是同一个字符串导致通道上收集不到足够的同意票。另外一个原因是链码名称写错一个组织用approval另一个组织用approval_1commit 时当然对不上。解决在 CLI 容器里执行peer lifecycle chaincode queryinstalled把返回的Package ID原样复制到所有组织的 approve 命令里。在 commit 之前用peer lifecycle chaincode checkcommitreadiness -c mychannel -n approval -v 1.0 --sequence 1检查各组织的同意状态直到所有组织都显示true再 commit。5.4 组织间数据不同步gossip 与锚节点没配明白现象org1 的 peer 提交了一笔审批org2 的 peer 查询不到或者过很久才同步。原因peer 之间的数据同步依赖 gossip 协议gossip 需要知道每个组织的锚节点。如果configtx里没有配置 AnchorPeer或者 anchor peer 更新交易没有提交成功两个组织的 peer 之间就无法互相发现。解决确认configtx.yaml的每个组织段里配了AnchorPeers并执行peer channel update提交锚节点交易。更新后进入任意 peer 容器执行peer channel getinfo -c mychannel对比两个组织的区块高度如果高度不一致说明 gossip 还没恢复。5.5 CouchDB 富查询返回空索引文件没进链码包现象链码里用了GetQueryResult按金额范围查询第一次返回正确重启 peer 后或者换一个 peer 后查询结果为空。原因CouchDB 的富查询依赖索引索引定义放在链码目录的META-INF/statedb/couchdb/indexes/下。如果索引没放进链码包首次查询时 CouchDB 会全表扫描可能偶发返回空结果而且性能极差。链码升级时没有携带新增的索引文件同样会出现这个问题。解决在链码源码目录下创建META-INF/statedb/couchdb/indexes/amountIndex.json内容类似{ index: { fields: [docType, amount] }, name: amountIndex, type: json }逻辑说明fields里的字段必须和链码结构体的 JSON tag 一致docType是你写入状态时约定的类型标识。加完索引后重新打包链码走一遍 install、approve、commit历史数据会自动建索引。平时排查这类问题时可以直接用 curl 请求 CouchDB 的_index接口确认索引是否存在于对应数据库。6. 验证与进阶从区块高度到两级会签的三步改造资源跑通并不代表万事大吉答辩或实际落地前我建议做三件事来验证系统是否可信。第一步是验证数据真的写进了链。进 CLI 容器执行peer channel getinfo -c mychannel记录当前区块高度提交一笔审批后再查一次高度应该加一。更直观的办法是在终端里docker logs peer0.org1.example.com看链码容器的输出确认每次PutState都返回成功。这一步能挡住“看起来跑通、实际数据只落在内存”的假象。第二步是改一个字段走升级流程。比如在ApprovalRecord里加一个Remark字段然后重新打包链码、queryinstalled拿到新包 ID、approve 时把版本改成1.1、--sequence加一最后 commit。走完这套流程你对 Fabric 2.x 链码生命周期的理解基本就覆盖了考试范围。第三步是把单级审批升级成两级会签。在Steps数组的同一StepID下挂多个审批人状态机里判断当前步骤是否所有人都完成再决定是否进入下一步。如果涉及敏感意见把Comment挪到私有数据集合里用PutPrivateData写入。这三步做完这份毕设已经从“能用”变成了“有设计”。这套资源解压后自带完整源码、讲解文档和全部环境文件下载后先按文档把第 2 章的搭建流程跑一遍再对照第 5 章的踩坑清单排查基本不会卡太久。从那以后我每次拿到一套 Fabric 毕设源码都会强制走一遍peer channel getinfo看区块高度、翻链码容器日志、再查一次 CouchDB 索引确认数据真的写进链里了才算部署完成。希望帮到你。本文还有配套的精品资源点击获取