企业官网建设流程全解析

简介：这份毕业设计资料围绕高校学籍管理系统的分析与实现展开，面向软件工程、计算机相关专业需要完成课程设计或毕业论文的学生，也可作为 Java 桌面端信息管理系统入门练手的参考。压缩包共 24 个文件、约 323KB，以 java 源码与 class 编译文件为主体，配合 bak 备份、doc 论文与程序设计报告文档、mdb 数据库以及 ldb 临时锁文件，基本还原了一个小型管理系统的完整工程面貌。已有 348 人学习下载。读者可从中获取学生信息、课程成绩、学籍变动等模块的增删改查实现思路，参照 MainFrame 主界面与各功能类的分工来理解界面与业务的分层组织，并借助论文文档梳理需求分析、数据库设计、测试与部署的写作框架；将源码与文档对照阅读，既能用于答辩前的结构梳理，也便于改造成自己的课题版本。

1. 从一张纸质申请表说起

每学年开学的前两周，教务办公室的桌上总会堆起一摞纸质申请表：休学、复学、转专业、退学，每一张都要人工核对学籍状态、逐级签字盖章、再回头改一遍电子表格。学籍管理系统毕业论文如果只做到「学生信息增删改查」，答辩时很难撑住追问，因为真正的业务难点全在那条状态流转链上。这套方案把学籍异动审批当作主线，学生、辅导员、院系教务员、教务处四类角色围绕一张申请单流转，成绩、班级、专业、报表作为支撑模块。适合正在准备本科毕业设计或课程设计的同学，也适合要给院系做一套轻量教务工具的开发者。下面从需求拆解一路写到答辩脚本。

2. 需求拆解与技术选型：四类角色、六个模块与三条技术路线

2.1 角色与用例：一条异动主线撑起整个系统

学籍管理最容易犯的错是把功能平铺成菜单：学生管理、班级管理、成绩管理、课程管理，每个模块都是增删改查，做完发现系统没有「业务」。换一种切法，先定角色，再定每个角色在一条主线上做什么，模块自然就长出来了。

四类角色的职责边界要写进需求文档，不然后面权限设计会反复返工：

主线用例只有一条，但必须写透：学生填写异动申请并选择异动类型 → 辅导员初审 → 院系教务员复审 → 教务处终审 → 系统在同一事务内更新申请单状态与学生主表学籍状态 → 写入审计日志。这条链路上有三处校验：类型与当前状态是否匹配（休学中的学生不能再申请休学）、同一学期是否已有在途申请、审批人是否具备该节点的权限。

很多同学想在这条链上套一个通用工作流引擎，我不建议。工作流引擎的配置成本远高于收益，答辩时老师问「你这个流程引擎怎么配的」，答不上来反而扣分。手写一个三节点的状态推进，把状态枚举、节点枚举、流转规则写清楚，工作量可控，逻辑还全在自己手里。

除了主线，还有五个支撑模块要覆盖：学生基础信息维护（含照片上传）、专业与班级维护、课程与开课计划、成绩录入与绩点计算、统计报表与数据导出。六个模块合起来，功能点大约 40 个，对一份毕业论文来说体量刚好，再多就是给自己挖坑。

2.2 技术路线对比：SSM、Spring Boot 前后端分离与 Django 怎么选

选型不是比谁新，是比谁能在你能投入的时间里跑通并讲清楚。三条常见路线摆在一起看：

我一般推荐 Spring Boot 3 + Vue 3 这条线。理由很实际：前后端分离之后，前端可以单独打包部署，答辩现场用浏览器就能演示，不用背着 Tomcat 跑；接口层用 Knife4j 生成在线文档，老师翻文档就能看到你设计了哪些接口、参数是什么，比自己口头讲有用得多。

后端依赖不用堆太多，核心就几个：

<!-- pom.xml 关键依赖，版本按自己环境锁定，不要用 LATEST --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>easyexcel</artifactId> <version>3.3.4</version> <!-- 成绩导入导出，比 POI 省内存 --> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency>

数据库选 MySQL 8，字符集统一 utf8mb4，排序规则用 utf8mb4_general_ci。学籍数据里会出现少数民族姓名中的生僻字，utf8 三字节存不下，这个坑每年都有人踩。Redis 只在做登录令牌和字典缓存时才引入，别为了「技术栈丰富」硬加，答辩时被问「你 Redis 存了什么、过期策略是什么」答不出来很尴尬。

2.3 非功能需求：一致性、审计与导出

需求文档里如果只写功能，评阅意见大概率会出现「缺少非功能性设计」。学籍系统有三条必须写清楚：

第一是一致性。审批通过这个动作要改两张表：申请单的审批状态、学生主表的学籍状态。两者必须同事务，任何一步失败整体回滚。更隐蔽的是并发——同一个学生的两条异动单被两个教务员同时点通过，状态就会互相覆盖。处理方式在第四章展开。

第二是审计。谁在什么时间把某个学生的状态从「在籍」改成了「休学」，这条记录必须留痕且不可篡改。设计一张audit_log表，记录操作人、操作类型、目标对象、变更前后值、IP、时间，写入动作放在业务事务里，和业务一起成功或一起失败。

第三是导出。成绩单、学生名册、异动汇总都要能导出 Excel。五千条以内用 EasyExcel 同步导出，十几秒能完成；超过五千条改成分页查询加流式写出，避免一次性把整个结果集读进内存。这个阈值不是拍脑袋，是实测下来 JVM 堆内保持在合理范围的经验值。

3. 总体架构与数据库设计：三层结构与七张核心表的职责划分

3.1 分层结构与包组织

后端按 controller、service、mapper 三层切，配套 entity（数据库映射）、dto（入参）、vo（出参）三套对象。很多课设把 entity 直接当入参和出参用，结果是前端多传一个字段就能改到不该改的列，比如学生自己提交资料时把status一起传上来。DTO 和 VO 分离不是形式主义，它是接口的第一道防线。

com.example.edu ├── common 统一返回体 Result、全局异常处理、业务异常 BizException ├── config MyBatis-Plus 配置、跨域、登录拦截器 ├── controller 按角色拆：StudentController、AuditController、ScoreController ├── service 业务逻辑，接口与实现分离 ├── mapper 数据访问，复杂 SQL 写在 XML ├── entity 与表一一对应 ├── dto / vo 入参校验对象与出参展示对象 └── enums 学籍状态、异动类型、审批节点

分层之后，controller 只做三件事：接参、调 service、包装返回。所有业务规则下沉到 service，这样单元测试才有地方写。答辩时如果老师问「你的业务逻辑在哪」，直接打开 service 层给他看状态机校验那几行，比翻半天 controller 有说服力。

统一返回体建议固定成code / message / data三段，前端拦截器按 code 判断。全局异常处理器捕获BizException返回业务提示，捕获其他异常返回通用错误并记日志，不要把堆栈直接吐给前端。

3.2 学籍状态机与三张主表的字段设计

学籍状态不要用 0/1/2 这种数字，用有语义的字符串枚举：ENROLLED（在籍）、SUSPENDED（休学）、RESERVED（保留学籍）、QUIT（退学）、GRADUATED（毕业）、COMPLETED（结业）。数字状态在日志和排查时是黑匣子，看到status=3得回去翻注释；字符串状态一眼就能读出业务含义。

允许的流转关系用文字描述清楚，写进论文的「详细设计」章节：

• 在籍 → 休学、保留学籍、退学、毕业、结业
• 休学 → 在籍（复学）、退学
• 保留学籍 → 在籍（复学）、退学
• 退学、毕业、结业为终态，不再流转

学生主表、异动申请表、成绩表是整个系统的骨架，建表时把约束一次写对，后面能省掉大量排查时间：

CREATE TABLE student ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL COMMENT '学号，业务唯一键', name VARCHAR(50) NOT NULL, id_card VARCHAR(32) NOT NULL COMMENT '身份证号，入库前加密或脱敏存储', gender TINYINT NOT NULL DEFAULT 0 COMMENT '0未知 1男 2女', major_id BIGINT NOT NULL, class_id BIGINT NOT NULL, enroll_date DATE NOT NULL COMMENT '入学日期，禁止用字符串存', status VARCHAR(20) NOT NULL DEFAULT 'ENROLLED', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', deleted TINYINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_student_no (student_no), UNIQUE KEY uk_id_card (id_card), KEY idx_class_status (class_id, status) ) COMMENT '学生学籍主表'; CREATE TABLE enrollment_change ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, change_type VARCHAR(20) NOT NULL COMMENT 'SUSPEND/RESUME/TRANSFER_MAJOR/QUIT', from_status VARCHAR(20) NOT NULL COMMENT '申请时的学籍状态快照', to_status VARCHAR(20) NOT NULL COMMENT '审批通过后的目标状态', apply_reason VARCHAR(500) NOT NULL, effective_term VARCHAR(20) NOT NULL COMMENT '生效学期，如 2024-2025-1', audit_status TINYINT NOT NULL DEFAULT 0 COMMENT '0待审 1通过 2驳回', current_node VARCHAR(20) NOT NULL DEFAULT 'COUNSELOR' COMMENT '当前审批节点', applicant_id BIGINT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_student_type_term (student_id, change_type, effective_term) ) COMMENT '学籍异动申请单'; CREATE TABLE score ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, term VARCHAR(20) NOT NULL, score DECIMAL(5,2) NULL COMMENT '百分制，NULL 表示缺考', exam_type TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 2补考 3重修', grade_point DECIMAL(3,2) NULL COMMENT '绩点，服务端计算后写入', UNIQUE KEY uk_stu_course_term_type (student_id, course_id, term, exam_type) ) COMMENT '学生成绩表';

enrollment_change上的唯一索引uk_student_type_term是这套设计里最关键的一条约束，它从数据库层挡住了「同一学生同一学期重复申请同一类异动」这种脏数据。from_status存快照而不是每次回溯计算，是为了在审批链很长时仍能还原申请提交那一刻的状态。

3.3 几个必须提前定下的设计取舍

第一个取舍：学生表要不要冗余存专业名和班级名。我的做法是只存major_id和class_id，展示时联表或用一次批量查询补齐名称。冗余字段在专业调整时会变成脏数据，改一次专业要同步更新几百条学生记录，漏一条就是数据不一致。如果确实有列表查询性能压力，用缓存或视图解决，别用字段冗余。

第二个取舍：删除用物理删除还是逻辑删除。学籍数据一律逻辑删除，deleted标记加全局过滤。学生退学不代表记录可以消失，成绩、异动历史都要能追溯。物理删除还会让外键悬空，成绩表里出现一堆找不到人的记录。

第三个取舍：成绩归档要不要单独建表。如果系统只服务在校生，一张score表够用；如果考虑毕业后成绩单补打，建议加一张归档表，毕业时把成绩整体迁过去。课设阶段可以不做，但论文的「系统扩展性」一节把这一点写出来，是加分项。

第四个取舍：身份证号怎么存。明文存储加完整展示，是答辩时最容易被追问的点。做法是入库加密或至少脱敏，列表页只展示前六位和后四位，导出时按角色判断是否有权查看完整号码，操作日志里绝不打印完整身份证。

4. 核心模块实现：异动审批、成绩导入与数据权限

4.1 学籍异动：状态机校验 + 行锁 + 幂等落库

异动审批是整个系统里唯一有「状态推进」语义的地方，也是最容易写错的地方。先把合法流转关系收敛到一个枚举类里，任何审批动作都先过这道校验：

public enum StudentStatus { ENROLLED, SUSPENDED, RESERVED, QUIT, GRADUATED, COMPLETED } public final class EnrollmentStateMachine { // 白名单：key 为当前状态，value 为允许迁移到的目标状态集合 private static final Map<StudentStatus, Set<StudentStatus>> ALLOWED = Map.of( StudentStatus.ENROLLED, EnumSet.of(StudentStatus.SUSPENDED, StudentStatus.RESERVED, StudentStatus.QUIT, StudentStatus.GRADUATED, StudentStatus.COMPLETED), StudentStatus.SUSPENDED, EnumSet.of(StudentStatus.ENROLLED, StudentStatus.QUIT), StudentStatus.RESERVED, EnumSet.of(StudentStatus.ENROLLED, StudentStatus.QUIT) ); public static void check(StudentStatus from, StudentStatus to) { Set<StudentStatus> targets = ALLOWED.getOrDefault(from, EnumSet.noneOf(StudentStatus.class)); if (!targets.contains(to)) { throw new BizException("当前学籍状态为 " + from + "，不允许变更为 " + to); } } }

ALLOWED用不可变 Map 初始化，避免运行期被误改。终态（退学、毕业、结业）没有出现在 key 里，自然就没有任何出口，这比写一堆 if-else 判断更不容易漏。

审批落库时要解决两个问题：同一学生的两条单据并发审批、同一条单据被重复点击通过。前者靠行锁，后者靠幂等判断：

@Transactional(rollbackFor = Exception.class) public void approve(Long changeId, Long auditorId, boolean pass, String remark) { EnrollmentChange change = changeMapper.selectById(changeId); if (change == null) { throw new BizException("申请单不存在"); } // 幂等：单据已是终态，直接返回，不重复改学籍 if (change.getAuditStatus() != AuditStatus.PENDING) { return; } // 行锁：锁住学生主表记录，防止同一学生两条单据被并发审批 Student student = studentMapper.selectForUpdate(change.getStudentId()); if (pass) { EnrollmentStateMachine.check( StudentStatus.valueOf(student.getStatus()), StudentStatus.valueOf(change.getToStatus())); student.setStatus(change.getToStatus()); studentMapper.updateById(student); // 乐观锁 version 自增 change.setAuditStatus(AuditStatus.APPROVED); } else { change.setAuditStatus(AuditStatus.REJECTED); } change.setAuditRemark(remark); changeMapper.updateById(change); auditLogService.record(auditorId, "ENROLLMENT_CHANGE", changeId, remark); }

行锁对应的 SQL 写在 XML 里：

<select id="selectForUpdate" resultType="com.example.edu.entity.Student"> SELECT * FROM student WHERE id = #{id} AND deleted = 0 FOR UPDATE </select>

几点说明。FOR UPDATE必须在事务内执行，否则锁在语句结束就释放了，等于没加。幂等判断放在行锁之前还是之后要权衡：放在前面能快速返回、减少锁竞争，代价是极小概率下的竞态；放在锁之后更严格但会多一次加锁。我的做法是前面先判一次快速返回，加锁后再判一次兜底，两个判断都不贵。updateById依赖实体上的@Version注解生效，需要提前在 MyBatis-Plus 配置里注册乐观锁插件，否则 version 字段只是摆设。

4.2 成绩导入：先全量校验，再单事务写入

成绩录入有两种入口：单条录入和 Excel 批量导入。单条录入简单，难的是导入——教务员给的表格里一定有错行，学号写错、课程代码不存在、成绩填了 120 分、同一个学生同一门课出现两行。如果边读边写，写到第 300 行报错，前面 299 条已经进库了，教务员只能手工删数据。

正确的顺序是：全量读取 → 逐行校验 → 有错误整批拒绝并返回错误清单 → 全部通过后在一个事务里批量写入。

public ImportResult importScores(MultipartFile file, String term) { List<ScoreRow> rows; try { // 表头与 ScoreRow 字段一一对应，统一按字符串读取，避免学号前导零丢失 rows = EasyExcel.read(file.getInputStream()) .head(ScoreRow.class).sheet().doReadSync(); } catch (Exception e) { throw new BizException("文件解析失败，请使用系统提供的模板"); } List<String> errors = new ArrayList<>(); Set<String> seen = new HashSet<>(); Set<String> studentNos = new HashSet<>(); Set<String> courseCodes = new HashSet<>(); for (int i = 0; i < rows.size(); i++) { ScoreRow row = rows.get(i); int lineNo = i + 2; // 表头占一行，报错行号与 Excel 一致 if (!seen.add(row.getStudentNo() + "#" + row.getCourseCode())) { errors.add("第" + lineNo + "行：该学生本门课程已在本文件中重复"); continue; } if (row.getScore() != null && (row.getScore() < 0 || row.getScore() > 100)) { errors.add("第" + lineNo + "行：成绩必须在 0 到 100 之间"); } studentNos.add(row.getStudentNo()); courseCodes.add(row.getCourseCode()); } // 批量校验学号、课程代码是否存在，一次查询代替逐行查库 Set<String> existStudents = studentMapper.selectExistingNos(studentNos); Set<String> existCourses = courseMapper.selectExistingCodes(courseCodes); for (int i = 0; i < rows.size(); i++) { int lineNo = i + 2; if (!existStudents.contains(rows.get(i).getStudentNo())) { errors.add("第" + lineNo + "行：学号 " + rows.get(i).getStudentNo() + " 不存在"); } if (!existCourses.contains(rows.get(i).getCourseCode())) { errors.add("第" + lineNo + "行：课程代码 " + rows.get(i).getCourseCode() + " 不存在"); } } if (!errors.isEmpty()) { return ImportResult.fail(errors); // 一条都不写入 } return scoreService.saveBatchWithGradePoint(rows, term); }

关键参数和取舍说明：doReadSync一次性读入内存，适合课设规模（几千行）；如果导入量上万，改成PageReadListener分批。行号用i + 2是因为第 1 行是表头，报错信息必须和用户在 Excel 里看到的行号一致，差一行就要多解释半天。学号和课程代码的校验用IN批量查一次，避免循环里查库——五百行数据循环查库就是五百次网络往返，慢得能让人怀疑人生。

绩点计算放在 service 里，不放在数据库：

public static BigDecimal toGradePoint(BigDecimal score) { if (score == null || score.compareTo(new BigDecimal("60")) < 0) { return BigDecimal.ZERO.setScale(2); } // 常用 4.0 制：(分数 - 50) / 10，60 分对应 1.0，100 分对应 5.0 return score.subtract(new BigDecimal("50")) .divide(BigDecimal.TEN, 2, RoundingMode.HALF_UP); }

绩点算法各校不同，有的用 4.0 制、有的用 5.0 制，有的分段映射。方案里要把公式写成常量或配置项，论文里单独用一小节说明「本系统采用的计算规则及其出处」，被问到时不至于临场编。平均绩点用学分加权：Σ(绩点 × 学分) / Σ学分，分母为零时要单独处理，直接除会抛算术异常。

4.3 数据权限：辅导员只看自己班，教务员只看本院系

权限分两层。功能权限解决「能不能进这个页面、能不能调这个接口」，用角色码加拦截器判断；数据权限解决「进去以后能看到哪些行」，这一层很多课设直接忽略了，结果辅导员登录后能查到全校学生，是典型的越权。

数据权限的实现有轻有重。轻的做法是在查询条件里拼子查询，表达清楚、改起来直观：

SELECT s.id, s.student_no, s.name, s.status, c.class_name FROM student s JOIN class c ON c.id = s.class_id WHERE s.deleted = 0 -- 辅导员：只查自己所带班级 AND (#{role} <> 'COUNSELOR' OR s.class_id IN (SELECT class_id FROM sys_user_class WHERE user_id = #{userId})) -- 院系教务员：只查本院系 AND (#{role} <> 'DEPARTMENT' OR s.major_id IN (SELECT major_id FROM sys_user_major WHERE user_id = #{userId}))

这段 SQL 的好处是可读，缺点是括号里的条件会让优化器放弃部分索引。学生表规模在一两万条时影响可以忽略，规模上去了再改成 MyBatis 拦截器按注解动态拼装 SQL。论文里把这个演进路径写清楚，比直接贴一段看不懂的拦截器代码更有价值。

角色与班级、院系的关联用两张中间表sys_user_class、sys_user_major维护，不要在学生表上直接挂一个「辅导员姓名」字段。人员轮岗是常态，关联表换一行记录就能交接，字段方式要批量改数据。

5. 避坑与排查：五处最容易在答辩现场翻车的地方

5.1 数据层：并发审批与部分成功

现象一：同一学生的两条异动单都被审批通过，学籍状态来回跳。原因是审批逻辑先查后改，两个请求同时读到「在籍」，各自算出目标状态再写回，后写的覆盖先写的。解决方式是审批前对学生主表加行锁（SELECT ... FOR UPDATE），并在申请单上保留唯一索引作为最后一道闸。

现象二：成绩导入报错后，库里多出一半数据。原因是循环里逐条insert且没有统一事务，异常抛出时前面的已经提交。解决办法是把「校验」和「写入」彻底分开：校验阶段只读不写，收集全部错误；写入阶段用@Transactional包住批量插入，任何一条失败整体回滚。对外返回的提示要说清「本次导入 0 条成功，共 12 处错误」，别只说「导入失败」。

现象三：删除学生后，成绩列表里出现空白行。物理删除导致成绩表里的student_id找不到对应记录，联表查询出来姓名是 null。学籍数据一律逻辑删除，并在所有查询里带上deleted = 0；如果用的是 MyBatis-Plus，配置全局逻辑删除后别忘了手写 SQL 也要加这个条件。

5.2 业务层：时间、脱敏与前导零

现象四：休学半年的时间算错，跨年查询漏数据。根因是用varchar存日期，比如2024.9.1、2024-9-1、2024/09/01三种格式混在一张表里，比较和相减全靠字符串。解决方式是日期字段统一用DATE、DATETIME，学期这种复合概念单独编码成2024-2025-1的固定格式并存成字符串，查询时按前缀匹配。历史数据用一次性脚本清洗，别指望在业务代码里兼容多种格式。

现象五：Excel 导入的学号前导零丢了，或者变成 1.23457E+12。因为 Excel 把单元格识别成数字。解决方式有三层：导出的模板里把学号和身份证列预设为文本格式；读取时统一按字符串接收，不用数值类型；入库前用正则校验学号格式，不匹配的直接报错行号。身份证末位的X也属于同类问题，按字符串处理一次解决。

另外提醒一条容易被忽略的：日志和异常信息里不要打印完整身份证号、手机号。答辩老师翻你的控制台输出，看到一整屏明文身份证，这个印象分基本就没了。

6. 验收与答辩：用一条主线脚本串起全部功能点

验收不是把功能挨个点一遍，而是按角色、按主线走一遍完整流程，每一步都能对上需求文档里的条目。我一般会提前准备一张验收表，自己先跑一遍，答辩时它就是演示脚本。

演示脚本按这个顺序走：先用教务处账号展示全局统计和学籍分布，切到学生账号提交一条休学申请，切回辅导员账号初审，再切院系教务员复审、教务处终审，最后回到学生端看到状态已经变成「休学」。这一条链路走完，四类角色、状态机、权限、日志、事务全展示到了，比按菜单从左点到右高效得多。

有个技巧值得单独说：主动演示系统如何拒绝非法操作。大多数同学只演示成功路径，点哪都通，看起来顺，但老师心里会犯嘀咕——这系统到底有没有校验？我会在演示完主线后，故意用休学中的学生再提一次休学，让页面弹出「当前学籍状态为 SUSPENDED，不允许重复申请休学」。这一下比讲十分钟设计思路都管用，因为它证明了状态机是真的在跑，不是摆设。

还有一件事得提前做：演示数据和测试数据必须隔离。我曾经在答辩前一天把测试库直接拿来演示，首页统计显示在校生三千多人，而实际院系只有六百人，老师随口问了句「你们院有这么多学生？」，场面一度很尴尬。从那以后我每次演示前都强制走一遍初始化脚本加验收清单：清库、灌演示数据、跑一遍主线、检查首页统计数字。这套动作花不了十分钟，但能挡住绝大多数现场翻车。

论文的章节顺序也建议按验收逻辑排：需求分析对应用例和角色，总体设计对应架构和表结构，详细设计对应状态机和核心代码，测试章节直接放这张验收表和实际截图。写完之后自检一遍——每一张表、每一段代码，能不能在演示里找到对应的那一分钟。希望帮到你。

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