简介这是一套面向计算机专业本科生的毕业设计与课程设计实战资源聚焦农产品质量安全痛点基于Java技术栈构建区块链赋能的溯源平台解决传统农业供应链信息不透明、数据易篡改等核心问题。资源包含完整可运行的SpringBoot后端系统、Vue前端界面及配套学术论文代码经导师指导并获99分高分评价特别适合毕业设计选题、课设开发或Java区块链入门实践。压缩包共1098个文件涵盖255个Java源码、274个编译类文件、193个XML配置、80个Vue组件及84个JS脚本辅以SQL建表语句、YML配置、BAT启动脚本等总大小8.63MB结构清晰、模块分明小白按说明即可本地部署运行。已有66人下载学习提供从环境搭建、链上存证逻辑到前后端联调的完整闭环方案附带Excel工具类、代码生成器实现等实用细节显著降低区块链项目落地门槛。 每年毕业季我都能看到大量基于区块链的XX平台这种毕业设计选题但答辩时真正能把系统跑起来、把原理讲明白的十个里面可能不到两三个。大多数人是拿着网上的开源代码改个名字PPT里画几条链式结构的图评委一问你这个区块链为什么不可篡改数据到底存在哪立马卡壳。今年带学弟做了一套基于Java的农产品溯源平台源码、论文、演示全走通了一遍整个过程复盘下来信息量很大想分享给正准备做类似选题的人尤其是打算用区块链方向做毕设和课程设计的同学。这个项目的定位很清晰用Java技术栈Spring Boot Vue MySQL实现一个农产品溯源系统核心是让消费者扫码就能看到农产品的全生命周期信息从种植、加工、质检、仓储到物流配送每一步的关键数据都会写入一条自己实现的轻量区块链中。和市面上那些只做增删改查的朴素溯源系统相比它的价值在于真正实现了防篡改校验——数据库中任何一条记录被别人改过链上验证立刻能发现这对农产品安全、品牌信任这类场景非常有说服力。我也把从搭建到跑通再到论文撰写的完整经验整理成文适合准备做相关方向毕业设计的本科生也适合想快速理解区块链在Java后端里如何落地的开发者。1. 为什么这个毕设选题值得做从市场需求反推技术方案1.1 农产品溯源的真实痛点先想清楚一个问题农产品溯源到底解决什么普通消费者买一盒草莓包装上贴着产地直供的标签但大多数人无从验证标签信息的真假。过去行业内有一种很普遍的玩法是贴牌某个产区出了食品安全问题不良商家换个包装继续卖消费者根本追不到源头。政府和企业都建过中心化的溯源系统记录也存在统一数据库里但中心化数据库最大的问题是一旦管理员有权限改数据或者数据库被入侵历史记录可以被静默修改可信度就大打折扣。这就是区块链切入溯源场景最顺的逻辑农产品从田间到餐桌的每个环节由不同的参与方记录信息这些记录按时间顺序一个接一个打包成区块、通过哈希值链在一起。任何人想篡改任何一个节点的数据后续所有区块的哈希都会对不上篡改成本高到不划算天然适合多方参与、互不信任、需要公开追溯的场景。1.2 为什么技术选型上不直接用以太坊而是自研轻量链做毕设时很多同学下意识就想接以太坊用智能合约存哈希。我不建议一上来就这么干原因有三条都是实际踩过坑才得出来的结论。第一毕设的时间和精力有限。接以太坊意味着要部署Ganache或者测试网节点要配MetaMask钱包要写Solidity合约还要处理Java和合约交互的web3j依赖。这一套组合拳打下来光环境调试就能耗掉两三周而项目其他功能可能还没动工。第二答辩时不好讲。评委大概率会问你的智能合约在链上执行了什么逻辑gas费怎么算部署在哪个网络如果只是简单调用转账或者存字符串答起来会很吃力。第三纯以太坊方案很难体现你自己的工作量和工程能力。课程设计和毕业设计最看重的是系统完整度和对技术的理解自己实现一条简化区块链从区块结构、哈希计算、工作量证明到校验逻辑全部自己写代码量、技术深度、答辩可讲性都远高于调一个现成链。一句话总结不是不能用联盟链或以太坊而是对大多数学生而言自研一条足够演示答辩的轻量链是性价比最高的选择。这套系统的实际实现里我们定义了一个Block类存区块数据BlockchainService负责区块生成与校验通过一个模拟的节点列表实现多节点广播业务层在每次新增溯源记录时调用链服务完成上链整条链路非常清晰。1.3 项目的整体模块与技术栈全景整个系统按经典的B/S架构展开前端使用Vue 2 Element UI搭建管理后台和溯源查询页后端使用Spring Boot 2.x作为业务服务MySQL存储结构化业务数据区块链部分自己实现模块间通过RESTful接口交互。总体模块可以拆成以下几个部分用户管理模块农户、加工企业、物流商、监管人员、消费者五类角色的注册、登录与权限控制。农产品批次管理模块为一批农产品创建唯一的批次编号记录品名、产地、种植/养殖信息。溯源记录管理模块各环节参与方按时间顺序提交溯源记录系统调用区块链服务完成上链并回写区块高度与交易哈希。区块链核心模块区块生成、SHA-256哈希、工作量证明、整条链的合法性校验。溯源查询模块消费者输入溯源码或扫描二维码查询该批次完整溯源时间线并展示链上验证状态。数据监管模块监管端可以按批次、企业、时间段等维度检索数据对疑似篡改记录进行链上核验。这个架构的优点在于每一层职责单一业务数据和区块链数据有明确边界。论文里画系统架构图也很容易说清楚评审不会觉得你有为了区块链而区块链的嫌疑。2. 溯源业务怎么落地角色权限、流程设计与上链数据维度2.1 五类角色与权限边界农产品溯源不是一个单一用户登录的系统它天然存在的多角色特性是论文中需求分析章节最加分的地方。实际项目里我设计了五类角色每类角色的核心操作和权限边界如下角色核心操作数据权限边界农户/养殖户创建批次、登记种植/养殖信息、提交采收信息只可操作自己名下批次加工企业登记加工/包装信息、上传质检报告编号只可操作自己参与加工的批次物流企业登记出库、运输、签收物流节点信息只可操作自己承运的批次监管机构查询全域批次、执行链上校验、标记异常记录全域只读校验不修改业务数据消费者扫码/输入溯源码查询只读无写入权限权限控制用Spring Security JWT实现后端通过注解拦截角色访问。这里的难点在于同一用户在不同批次中可能扮演不同角色比如一个大型农业公司同时是种植方和加工方所以判断权限时不能只认全局角色还要结合该批次关联的企业ID。这个细节在答辩时非常能体现工程思维的完整性。2.2 一条黄瓜从田头到餐桌的全流程为了让溯源流程具体化我用一个精品黄瓜批次走通完整链路这也是论文和演示视频中的核心用例。第一步农户老张在系统里注册并登录创建新批次填写产地、品种、播种日期、种植方式露天/大棚上传产地环境检测报告系统生成唯一的批次编号比如TRACE20250616001。这个批次号也是后续消费者扫码的溯源码。第二步老张陆续登记农事记录比如施肥记录和农药使用记录包括时间、操作人、用量、安全间隔期。这块数据对消费者来说最敏感也是防篡改的重点每次提交都会触发一次上链操作。第三步黄瓜成熟采摘老张提交采收信息包括采收日期、数量、质检采样编号。加工企业接手后登记清洗、切割、包装环节上传质检报告编号和结论合格才能进入下一步。第四步物流企业接单后登记出库时间、冷链车辆编号、装车温度运输途中每4小时上报一次温度数据到达分销中心后登记签收信息和收货温度。第五步黄瓜上架销售。消费者买到后扫码页面展示一条按时间线排列的完整记录产地信息、农事记录、采摘信息、加工信息、质检报告、物流轨迹。每种记录的右侧都显示一个链上已验证或链上验证失败的状态徽标这条设计是整个系统演示效果最强的部分。2.3 每一环到底要上链什么数据维度的选取原则知道流程还不够很多同学折在哪些数据该上链这个选择上。要说明的是区块链并不是把所有业务数据都塞进去。农产品溯源场景中有些数据需要上链有些数据不适合上链核心原则有三条关键节点要上链、大字段文件不上链、敏感隐私不上链。具体到实现每个上链记录在链上的data字段不是一条完整的大文本而是一个JSON摘要包含记录ID、批次号、操作类型、操作人ID、时间戳和业务关键字段的哈希值。比如农事记录上链时data字段会拼成{recordId:REC20260616001,batchId:TRACE20260616001,type:FERTILIZE,operatorId:U1001,time:1750000000,hash:一串业务关键字段的SHA-256值}。业务明细比如农药名称、用量表格仍然存在MySQL里但明细内容再取一次哈希和链上哈希比对就能判断MySQL里的记录有没有被人改过。我把这个设计叫作链上摘要链下明细它既保证了核心信息不可抵赖又绕开了区块链不适合存大字段、查询慢的先天缺陷。论文里把这个架构单独拆成一节去写评委通常会认为你确实理解了区块链的工程边界而不是只会写区块链是去中心化的这种课本话。3. 区块链核心模块实现从零手写一条能跑的轻量链3.1 区块结构与哈希计算区块链链的本质是每个区块里保存了前一个区块的哈希值环环相扣。整个模块我拆成Block和BlockchainService两个类前者负责数据模型后者负责链的运算操作。先看Block类关键字段设计如下public class Block { private int index; // 区块高度创世区块为0 private long timestamp; // 出块时间戳 private String data; // 业务摘要存溯源记录的关键信息 private String previousHash; // 前一个区块的哈希 private String hash; // 当前区块的哈希 private int nonce; // 工作量证明随机数 // 省略getter/setter }这里最容易被忽视的是previousHash的串联作用。生成区块时必须先从链上取出最后一个区块的hash放到新块的previousHash里再计算新块的hash。计算哈希的方式是用SHA-256对区块高度时间戳业务数据前一哈希nonce拼接成字符串后求摘要这样任何字段被改动最终哈希都会变化区块链的不可篡改特性就建立在SHA-256的碰撞抵抗性上。3.2 新增区块为什么生产环境不能随便用一个固定难度新增区块流程中有一个关于工作量证明的取舍。我见过很多教程代码里写死找到hash前四位为0的nonce但实际在毕设答辩时如果评委追问你这个共识机制为什么难度固定只回答为了省事会显得缺乏思考。我的做法是设计一个可配置的难度参数默认设为4含义是目标哈希前四位必须为0。难度的选取要权衡出块速度和算力消耗难度太低一两个循环就出块体现不了工作量难度太高比如设置为6学生机可能要等好几秒甚至十几秒演示时体验很差。我实测下来经典i5处理器的轻薄本难度为4时平均出块时间在100~300毫秒之间既不会卡界面又能明显看到nonce在累加搜索的调试日志演示效果最好。实际代码逻辑如下public Block addBlock(String data) { Block latest chain.get(chain.size() - 1); Block newBlock new Block(); newBlock.setIndex(latest.getIndex() 1); newBlock.setTimestamp(System.currentTimeMillis()); newBlock.setData(data); newBlock.setPreviousHash(latest.getHash()); mineBlock(newBlock, difficulty); chain.add(newBlock); return newBlock; } private void mineBlock(Block block, int difficulty) { String prefix 0.repeat(difficulty); String hash; do { block.setNonce(block.getNonce() 1); hash calculateHash(block); } while (!hash.startsWith(prefix)); block.setHash(hash); System.out.println(区块出块成功nonce block.getNonce() hash hash); }需要说明的是真实比特币的PoW是按概率指数级增长难度本质是能耗换信任。在溯源这类联盟链场景中参与方固定且准入可控不用复刻这种高能耗设计所以论文里我会把这里的PoW定位为模拟型共识用于教学演示和验证防篡改逻辑同时讨论可以怎样替换为更轻量的PBFT或权威证明。这样既做实了功能又回应了热搜里大家关心的区块链能耗问题论文的技术分析章节也有话可写。3.3 链合法性校验篡改操作是怎么被发现的校验逻辑是整个系统演示的灵魂。如果没有这个校验方法那这条区块链就只是一个带哈希的链表没有实际价值。实现时遍历链上每一个区块对每个区块重新计算哈希和区块里存的hash比对再判断current.previousHash是否等于previous.hash。public boolean isChainValid() { for (int i 1; i chain.size(); i) { Block current chain.get(i); Block previous chain.get(i - 1); String reHash calculateHash(current); if (!current.getHash().equals(reHash)) { return false; } if (!current.getPreviousHash().equals(previous.getHash())) { return false; } } return true; }这里有个非常关键的实操细节在校验之前必须把当前区块参与哈希的所有字段重新拼接一次拼接顺序要和出块时完全一致。很多同学的代码出块时拼的字符串是index timestamp data previousHash nonce校验时却用了另一个顺序导致区块没被篡改也校验失败误以为系统有bug。我把拼接逻辑统一抽到一个calculateHash方法里所有地方只认这一种拼法从根上杜绝了这类问题。演示校验效果的方式也很直观调用一个测试接口模拟管理员在管理端后台把某个农事记录的农药用量从500改成5000然后触发链上校验校验器会重新计算MySQL里明细记录对应的业务哈希发现和链上data里的摘要不一致立即返回第2个区块校验失败追溯记录被篡改。这个画面在答辩现场展示时几乎每个评委都会对这个设计点感兴趣。3.4 模拟多节点广播怎么让链看起来更真实纯单机链表离区块链感觉还是太远了为了让系统架构更饱满我实现了一个简化的多节点广播机制不需要真正部署多台服务器而是在同一个应用内维护多个Blockchain实例每个实例对应一个节点。具体做法是定义一个NodeManager内置3~5个节点每个节点内部持有自己的区块链副本。新增溯源记录上链时先由提交节点出块然后将区块广播给其他节点其他节点收到后校验新区块的前序哈希是否和本地链尾一致、区块哈希是否合法通过后追加到自己的链上。这样每次查询链状态可以对比多个节点的链高度和最后一个区块哈希只要一致就说明所有节点账本同步正常。当时我给每个节点起名叫供应商节点加工节点监管节点对应真实业务角色每个节点的日志里打印各自的出块和同步情况。论文实现章节配上这个设计区块链的分布式特征一下子就有了落点相比只有一个链对象的实现方式技术深度明显高一个档次。4. 链上链下协同MySQL和区块链在系统里到底怎么分工4.1 数据一致性问题的真实答案不是把区块链当数据库用整个项目中让我花最多时间思考的不是区块怎么写而是MySQL和区块链之间数据怎么同步。很多教程只强调区块链数据不可篡改却没告诉你真去做业务系统时明细数据根本离不开关系型数据库。农产品溯源记录里有图片URL、有几百字的农事说明、有各种查询条件这些塞进区块链的data字段既浪费存储查询性能也很差。所以系统的落地方式是两条线并行MySQL保存完整的业务明细充当系统的读模型区块链保存每次业务操作的摘要哈希充当系统的校验模型。一条完整记录落库后业务层把记录的ID、类型、操作人和关键字段的哈希值拼接成JSON调用区块链服务生成区块再将区块高度和区块哈希回写到MySQL对应记录的链证明字段中。这条流程我用一个事务注解方法实现确保了业务记录至少被保存成功后才发起上链。上链结果也单独记录状态字段如果某个环节因为哈希校验失败或节点同步异常系统不会假装这条数据已经上链而是打上上链失败标记并在监管端展示。4.2 溯源相关的MySQL表结构设计核心业务表我设计成了五张这里重点说最有代表性的两张。第一张是农产品批次表product_batchCREATE TABLE product_batch ( id BIGINT PRIMARY KEY AUTO_INCREMENT, batch_code VARCHAR(32) UNIQUE NOT NULL COMMENT 批次溯源码, product_name VARCHAR(64) NOT NULL COMMENT 产品名称, origin_place VARCHAR(128) COMMENT 产地, grow_method VARCHAR(32) COMMENT 种植方式大棚/露天, producer_id BIGINT COMMENT 所属农户/企业ID, status TINYINT DEFAULT 0 COMMENT 批次状态0进行中1已上市, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );第二张是溯源记录表trace_record它与区块链的绑定关系全在这张表里体现CREATE TABLE trace_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, record_code VARCHAR(48) UNIQUE NOT NULL COMMENT 记录唯一编码, batch_id BIGINT NOT NULL COMMENT 批次主键, record_type VARCHAR(32) NOT NULL COMMENT 环节类型GROW/HARVEST/PROCESS/QUALITY/LOGISTICS/SALE, operator_id BIGINT COMMENT 操作人ID, operator_name VARCHAR(32) COMMENT 操作人姓名, detail_json TEXT COMMENT 环节明细JSON包含用量、温度等扩展信息, biz_hash VARCHAR(64) NOT NULL COMMENT 业务关键字段SHA-256, block_index INT COMMENT 所在区块高度, block_hash VARCHAR(64) COMMENT 所在区块哈希, chain_status TINYINT DEFAULT 0 COMMENT 0待上链1已上链2上链失败, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_batch_time (batch_id, create_time) );写下这张表结构时有一个很深的体会biz_hash字段是整个溯源防篡改能力的锚点。这个哈希的拼接规则同样是固定的把detail_json里排除图片URL后的业务关键字段拼成字符串再取SHA-256这样哪怕只能看到MySQL数据库也无法绕过哈希伪造一条看似合法的记录因为哈希拿不到链上私钥重算。4.3 链上链下双存储的查询策略实际的溯源查询流程是这样的消费者请求/api/trace/{batchCode}时后端先从MySQL查出该批次详细记录并组装出一条带有批次信息的溯源时间线随后对每一条记录用biz_hash重新计算和对应区块data里的摘要做比对。比对结果决定这条记录显示已验证还是被篡改。这样做还有一个额外的好处可以把查询性能控制在毫秒级。区块链虽然理论上可以存所有数据但遍历所有区块做字符串解析非常慢而MySQL的索引查询在几千条记录内非常快篡改逐条校验也只涉及该批次的十几个区块开销很小。项目里我造了200个批次、每批12条记录的测试数据全链校验在500毫秒以内完成完全满足答辩演示的要求。5. 核心业务接口与扫码溯源演示闭环5.1 后端接口设计的几个关键点有了底层区块链模块业务接口反而变得脚手架化了但仍有必要说明设计中比较重要的几个点。新增批次接口POST /api/batch/create和新增溯源记录接口POST /api/record/add两者都在service层先写MySQL再调区块链服务上链。这里有一个并发问题值得注意如果两个请求同时上链可能会出现两个区块的前序哈希都指向同一个链尾的情况。我用synchronized关键字将addBlock方法加锁同时在区块链服务内部用版本号字段控制区块追加顺序确保一条链永远不会分叉。论文中可以把这段描述补充为并发上链的原子性控制比只贴代码更显深度。另一类接口是查询和校验接口查询接口返回的是统一的视图对象包含时间线列表、每个节点是否通过校验、整批次的链上验证摘要。这样一来前端不用关心任何区块链细节只管渲染结果接口隔离做得很干净。5.2 前端扫码与时间线展示前端部分我用Vue实现两个核心页面。管理端针对各角色提供新增批次、录入环节的表单页表单提交时调用后端上链接口页面会显示上链成功区块高度xxx的回执信息。消费者端是溯源查询页输入溯源码或者手机扫描二维码进入页面从上到下渲染一条时间线每个节点左侧是图标右侧是记录信息右上角是状态徽标。状态徽标是我认为最能打动评委的视觉设计绿色显示链上已验证红色显示数据校验失败。演示时先正常查询一次展示所有绿色然后修改数据库里一条记录的信息再查一次页面上那条记录立刻变红这种前后对比带来的冲击力比任何文字解释都有说服力。5.3 一节完整的演示流程建议复盘当时预答辩遇到的状况我建议正式答辩时按下面的顺序来演示第一步管理端登录农户账号创建新批次填写品名、产地提交后页面显示批次溯源码和创世区块信息。第二步依次录入种植、施肥、采收、加工、质检、物流六条记录每录一条都展示后台新增的区块信息。第三步登录消费者页面输入溯源码展示完整绿色时间线顺带说明链上摘要与链下明细的校验逻辑。第四步切换监管端账号模拟修改某条记录回到消费者页面刷新展示红色校验失败效果。第五步如果设备允许展示一下节点同步日志说明多个节点账本一致的状态。这套流程走完大约8分钟已经能覆盖系统的主要功能和技术亮点。我在源码里专门写了一个演示模式预置一批演示数据和账号就是为了避免现场临时录入导致网络或环境出问题。6. 论文写作重点与答辩预案光有代码还不能毕业6.1 论文目录与写作节奏源码和系统都不是终点答辩还需要论文来支撑你确实做了这个项目的说服力。这套项目的论文结构我按学校常规格式整理成了七章第一章 绪论介绍农产品安全背景、区块链在溯源领域的研究现状引用最近几年的文献说明研究意义。第二章 相关技术介绍区块链原理、共识机制、Spring Boot、Vue、MySQL、SHA-256。这里的核心是写清楚为什么采用轻量链而不是以太坊避免技术选型没有理由。第三章 需求分析从功能需求和非功能需求两个维度展开把角色用例图和流程图用文字和表格描述清楚。第四章 系统设计总体架构、功能模块划分、区块链数据结构设计、数据库设计。这是全文篇幅最重的部分。第五章 系统实现按模块展示核心代码和界面截图重点讲区块链核心模块与溯源模块的接口集成。第六章 系统测试包括功能测试用例表、链上篡改测试、节点同步测试、简单性能测试。第七章 总结与展望总结项目工作点出不足比如共识机制仍是模拟级未实现真正异步拜占庭容错后续可以替换为联盟链框架。写作节奏上我建议不要在前期花大量时间打磨文字先把代码跑通、界面截图、演示数据准备好再按章节填充文字。论文最怕的是系统还没完工就开始写写到后面功能变了前面大量文字要重写非常浪费时间。6.2 创新点怎么提炼才不假大空很多毕设论文的创新点写得过于虚什么打破信息孤岛推动数字化农业这种话基本等于没写。我建议把创新点落到可以演示、可以检验的工程层面这版论文里的三个点供参考一是链上链下双存储。轻量区块链存摘要、MySQL存明细解决区块链不擅长大字段存储与查询的问题并设计了biz_hash关联校验机制。二是可配置难度的模拟工作量证明让区块生成速度在不同演示环境下都能保持流畅规避了传统PoW高能耗的弊端做成了适配教学场景的轻量共识。三是多节点模拟同步。单进程中维护多节点账本副本通过区块广播和校验模拟分布式账本一致性让系统在不必部署集群的前提下具备可演示的分布式特性。这三点每一个都有对应代码和演示效果答辩老师追问也撑得住因为它们不是概念包装而是实实在在的实现取舍。6.3 高频答辩问题与回答话术把评委最爱问的问题整理了一下一共四类高频题提前准备不吃亏。第一个问题区块链和传统数据库有什么区别你为什么要两条都存回答思路传统数据库支持高效查询和灵活更新但中心化管理员能改数据区块链不可篡改却查询慢、不适合存大字段。双存储让MySQL服务业务查询让区块链做防篡改校验各取所长。第二个问题你的链数据存在哪台机器上如果这台机器被入侵了怎么办回答思路系统设计了多节点副本每份记录至少同步到三个模拟节点单点数据被改节点间对账立刻会发现差异同时引入了biz_hash改数据必须同步改链而链上哈希依赖工作量证明重算成本足够高。第三个问题你这个工作量证明难度值是什么决定的回答思路难度值是共识参数决定出块速度和验证成本设置成4是因为演示环境实测响应最好。生产环境中可以按参与节点数和出块目标时间自动调整论文展望里已经写了这个优化方向。第四个问题如果项目里某个环节的参与方故意不配合不上传溯源数据怎么办回答思路溯源系统解决的是上传之后不能篡改的手性问题不上传属于业务流程执行问题解决方案是监管端设置批次状态检测和逾期提醒功能某环节超过时限未登记该批次会被自动标记为异常不允许进入市场流通。这些问题我在源码的README里也附了对应的详细答案建议在准备阶段自己亲手把这些问题改写成自己的话不要死记硬背评委能感觉到你是真的理解还是背稿。最后再分享一个实际操作中的经验如果收到的源码里自带论文不要拿过来直接提交。花三个晚上从头到尾读一遍代码确认每个核心模块的作用和关键方法在哪个类里然后把自己当成项目作者照着论文目录重新梳理一遍逻辑把论文里和代码对不上的地方改掉。答辩的时候引导老师看你的演示和代码实现比你背十页稿子都管用。这套Java版区块链溯源平台做下来我从最初对区块链只停留在概念层面到最后能自己写出区块类、讲清防篡改原理、给出共识方案选型理由这个成长过程本身就是这个毕设项目最大的收获。本文还有配套的精品资源点击获取