简介：一套基于SpringBoot与Vue.js前后端分离的智慧校园管理系统完整Java源码，面向正在学习Java企业级开发、需要真实项目练手的在校学生，也适合参考校园信息化建设方案的技术人员。压缩包共1134个文件，大小32.49MB，核心包含197个Java源文件（后端业务逻辑与接口）、90个Vue组件（前端页面）、157个JavaScript脚本、50个CSS样式，并配有SVG/PNG图标、GIF演示图、Word/PDF说明文档以及安装、运行、构建批处理脚本，目录结构清晰，便于快速启动与二次开发。目前已有56人浏览学习，整体完整度较高，从可行性分析、技术选型到模块实现均体现企业级工程化思想。系统采用B/S架构，以SpringBoot整合MyBatisPlus与MySQL 5.7，前端基于ElementUI，业务覆盖用户身份信息管理、多媒体素材统一存储与调用等校园核心场景；通过学习源码可掌握前后端分离项目组织方式、自动化构建流程，以及用信息化手段提升校园综合管理水平的具体实现。

1. 智慧校园管理系统，为什么偏偏要用 SpringBoot 重写一遍

拿到“基于 SpringBoot 的智慧校园管理系统”这个标题时，你大概率已经在网上翻过十几个“XX管理系统源码”的帖子了——有的用 SSM，有的用 JSP，有的干脆就是培训班大作业。但真正拿到企业里或放到毕业设计答辩现场，SpringBoot 版本几乎是唯一能让你少被追问的选型。原因不在于 SpringBoot 本身多新奇，而是它把“配置地狱”变成了“约定大于配置”，把原来 SSM 里几十行 XML 的装配工作压缩成几个注解，同时保留了 Spring 生态里事务、AOP、依赖注入这些真正值钱的能力。智慧校园这类系统看着简单，实际一拆就分成师生管理、课表考勤、门禁/消费、消息通知、数据报表好几条业务线，没有一套统一的工程骨架，光维护依赖版本就够喝一壶。

这套系统适合谁？一类是还在做毕设、需要把“完整源码 + 论文 + 演示视频”一次凑齐的学生；另一类是中小型学校的信息化负责人，想用最低成本把纸质流程搬到线上。它解决的痛点是：一个单体应用把用户认证、权限控制、业务 CRUD、文件上传、报表导出全部包住，部署时只需要一个 JDK 和一个 Jar 包，连独立中间件都可以后置。本文就按我实际做过的落地路径，把这套系统的架构拆开、代码贴出来、坑提前告诉你。

2. 架构与技术选型：为什么是 SpringBoot + MyBatis-Plus，而不是别的组合

2.1 单体能跑就先别拆微服务

我见过不少人在做智慧校园系统时，一上来就规划 Nacos、Gateway、OpenFeign，把系统拆成五个微服务。实话说，对绝大多数校级项目，这是在给自己挖坑。一个学校几千师生，并发量峰值出现在选课和查成绩这几个场景，单体完全扛得住，而且单体能让你把精力花在业务边界和权限模型上，而不是花在服务间调用失败的排错上。

常见做法是 SpringBoot + MyBatis-Plus + MySQL + Redis 四件套，再按需引入 SpringDoc 生成接口文档。选 MyBatis-Plus 而不是 JPA，是因为校园系统里有大量多条件组合查询、分页和批量导入这种操作，MyBatis-Plus 的 LambdaQueryWrapper 能让你少写一半 XML，且条件拼接时不容易漏掉 Dynamic SQL 的坑。JPA 在关联查询复杂时，Hibernate 自动生成的 SQL 往往不是你想要的那条，排查成本高。SpringData JDBC 又太薄，事务和逻辑删除都要自己写。

2.2 数据库与缓存的分工：Redis 只存热数据

数据库用 MySQL 5.7 或 8.0 都行，InnoDB 引擎，字符集 utf8mb4。核心表包括：用户表（统一账号体系）、学生表、教师表、班级表、课程表、选课表、考勤表、通知表、菜单权限表。你需要为每张表预留 create_time、update_time、deleted 三个字段，逻辑删除用 MyBatis-Plus 的@TableLogic注解，比物理删除安全得多。

Redis 在这个系统里做三件事：一是存 JWT Token 的黑名单和用户会话；二是缓存班级课表、学期校历这类读多写少的数据；三是做选课时的分布式锁，防超选。别把全校所有数据都塞进 Redis，默认 TTL 设 10 到 30 分钟已经足够。下面是一个典型的 Redis 缓存 key 设计：

school:cache:schedule:2025:term1:{classId} school:cache:user:info:{userId} school:lock:course:select:{courseId}

2.3 最小可用依赖清单：直接能抄的 pom.xml 片段

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> </dependency> </dependencies>

SpringBoot 版本用 2.7.18 而不是 3.x 原因很简单：大量学生项目还在用 JDK 8，SpringBoot 3 强制要求 JDK 17，且 javax 包名变成 jakarta，旧教程里的代码很多直接编译不过（你这个项目就经常被“springboot版本太高”这种问题卡住）。如果你是新起盘且 JDK 已经是 17+，用 3.2.x 也行，但拦截器、过滤器、Redis 序列化的写法都要核对版本差异。上面这段依赖里，最容易被忽略的是spring-boot-starter-validation——没有它，@Validated注解就是摆设，Bean Validation 的依赖不会被 web starter 自动带进来。

2.4 工程目录结构：按业务域划分，别按技术层划分

com.school.smartcampus ├── common // 统一返回结果、全局异常、常量 ├── config // MyBatisPlus分页插件、Redis序列化、Cors、拦截器注册 ├── controller // 只做参数接收和结果返回 ├── service // 业务逻辑 ├── mapper // MyBatis-Plus 接口 ├── entity // 数据库实体 ├── dto // 前端入参对象 ├── vo // 前端出参对象 ├── utils // JWT、导出Excel等工具 └── security // 登录认证、权限注解、拦截器

Controller 层做薄是有实际好处的—— 我接手过不少项目，Controller 里堆了上千行业务代码，事务注解写在 private 方法上失效、异常抛到前端变成 500 英文堆栈，这些问题都源自分层没做干净。按上面的结构，每个模块（如考勤模块）在 service 里完成事务和校验，controller 保持 30 行以内。

3. 核心模块落地：从登录鉴权到考勤签到，代码怎么才抄得动

3.1 JWT 登录与权限控制：拦截器 + 注解双管齐下

智慧校园系统里至少有三类角色（管理员、教师、学生），权限点差得很远：学生能看自己课表和成绩，教师能改成绩和点名，管理员能管所有基础数据。最省事的做法是登录时发 JWT，拦截器校验 Token 合法性，方法上用自定义注解做细粒度权限控制。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和 Swagger 文档 String uri = request.getRequestURI(); if (uri.contains("/auth/login") || uri.contains("/doc.html")) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token) || !token.startsWith("Bearer ")) { throw new BusinessException(401, "未登录或Token已过期"); } // 解析 Token 并存入 ThreadLocal，供 Service 层获取当前用户 Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); UserContext.set(claims.get("userId").toString(), claims.get("role").toString()); return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { // 防止内存泄漏，请求结束后清理 ThreadLocal UserContext.clear(); } }

这段代码有两个细节值得说。一是UserContext用 ThreadLocal 存当前登录人，后续 service 层拿 userId 就不用一层层传参了；二是afterCompletion里必须清理，否则 Tomcat 线程池复用线程时，下一个请求会读到上一个用户的身份——这是线上事故级别的隐患。拦截器写好之后，在 WebMvcConfigurer 里注册，注意排除静态资源和文件预览路径，不然图片都访问不了。

细粒度权限用注解做。自定义一个@RequireRole注解，value 里写允许访问的角色，用 Spring AOP 或拦截器里根据 handler 上的注解做判断。实际项目中我建议用 AOP 做，因为拦截器对 Controller 方法上的注解处理要小心 HandlerMethod 转换，AOP 更直观。就一套校园系统而言，用角色判断足够了，不需要引入 Spring Security 那套复杂体系——Spring Security 的过滤器链配置本身就是一个大坑，很多学生项目被它的默认表单登录和 CSRF 拦截搞到崩溃。

3.2 考勤签到与 Redis 防重复提交：代码就 30 行

考勤是智慧校园里最有“智慧”含量的模块。常见做法有两种：一种是老师开课，学生扫二维码签到；另一种是学生进教学楼时通过 Wi-Fi 或 NFC 打卡。单体系统里，二维码签到最容易实现，也最能讲清楚业务逻辑。

@Service public class AttendanceService { @Autowired private StringRedisTemplate redisTemplate; @Autowired private AttendanceMapper attendanceMapper; /** * 学生签到 * @param courseId 课程ID * @param studentId 学生ID * @param code 老师展示的签到码 */ public Result signIn(Long courseId, Long studentId, String code) { String key = "school:attendance:code:" + courseId; String cacheCode = redisTemplate.opsForValue().get(key); if (StringUtils.isBlank(cacheCode) || !cacheCode.equals(code)) { return Result.error("签到码错误或已过期"); } // 已签到直接返回，防止重复插入 String signKey = "school:attendance:signed:" + courseId + ":" + studentId; Boolean firstSign = redisTemplate.opsForValue() .setIfAbsent(signKey, "1", Duration.ofMinutes(10)); if (Boolean.FALSE.equals(firstSign)) { return Result.error("请勿重复签到"); } Attendance attendance = new Attendance(); attendance.setCourseId(courseId); attendance.setStudentId(studentId); attendance.setSignTime(LocalDateTime.now()); attendanceMapper.insert(attendance); return Result.success("签到成功"); } }

这个设计里最关键的是 Redis 的setIfAbsent——它天然是原子的，多线程环境下不会出现两个人同时签到都成功的问题。签到码存 10 分钟过期，签到记录存 10 分钟防重，时间窗口对齐，不需要额外引入分布式锁。如果你非要用数据库做幂等，千万记得给 (course_id, student_id) 加联合唯一索引，这是最后一道防线。我见过没用 Redis、只靠数据库查询判重的版本，一旦服务器重启导致缓存丢失，学生重复签到就出现了。

3.3 学生选课：MyBatis-Plus 分页与事务边界

选课是智慧校园系统里并发压力最大、也最容易被答辩老师追问的模块。核心需求：每门课有容量上限，学生只能选未满的课，且同一时间段不能冲突。

@Transactional(rollbackFor = Exception.class) public boolean selectCourse(Long studentId, Long courseId) { // 1. 分布式锁，防止并发超选 String lockKey = "school:lock:course:" + courseId; Boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", Duration.ofSeconds(5)); if (Boolean.FALSE.equals(locked)) { throw new BusinessException("选课人数过多，请稍后重试"); } try { // 2. 查课程容量 Course course = courseMapper.selectById(courseId); if (course.getSelectedCount() >= course.getCapacity()) { throw new BusinessException("该课程已选满"); } // 3. 幂等检查 + 选课记录 Long count = courseSelectMapper.selectCount( new LambdaQueryWrapper<CourseSelect>() .eq(CourseSelect::getStudentId, studentId) .eq(CourseSelect::getCourseId, courseId)); if (count > 0) { throw new BusinessException("不能重复选择同一门课"); } CourseSelect cs = new CourseSelect(); cs.setStudentId(studentId); cs.setCourseId(courseId); cs.setSelectTime(LocalDateTime.now()); courseSelectMapper.insert(cs); // 4. 课程已选人数 + 1（乐观更新） courseMapper.update(null, new LambdaUpdateWrapper<Course>() .eq(Course::getId, courseId) .setSql("selected_count = selected_count + 1")); return true; } finally { redisTemplate.delete(lockKey); } }

这里有三个点容易翻车。第一，@Transactional注解写在selectCourse上，但如果这个方法是被同类中的另一个方法调用，事务会失效——Spring 的 AOP 代理只对外部调用生效，this.selectCourse()这种写法会绕过代理。第二，Redis 锁必须放在事务外面，因为事务提交是在方法返回前，如果锁在事务方法内部释放，可能出现锁已删但事务还没提交，另一个线程读到的还是旧数据。第三，selectedCount用setSql做自增，而不是先查后改，这样能避免并发下两个线程读到同一个旧值。

3.4 消息通知模块：事件机制还是定时扫描

校园系统的消息通知要覆盖三种场景：选课成功通知、考勤异常通知、公告推送。最简单的落地方式是不引入消息队列，直接在业务代码里事务结束后调用通知服务，把记录插入通知表，前端轮询或 WebSocket 推送。不过如果你在热词搜索里有“springboot整合activemq”的需求，说明你已经在往低耦合的方向想了——对智慧校园这个规模，ActiveMQ 或 RabbitMQ 属于“可以但没有必要”，优先把业务做完，引入 MQ 只会增加部署和排障负担。

真实的做法是：通知表 + 异步线程池。业务方法执行成功后，用@Async注解或手动线程池发通知，通知内容包括 title、content、target_user_id、type、is_read 五个字段。前端拿到未读消息数，点进去标记已读。为了避免服务重启导致通知丢失，可以在通知表加一个 status 字段，启动时扫一遍 status=0 的数据重发。这一套做下来比引 MQ 实用得多。

4. 数据库设计与查询性能：为什么你的列表页越翻越慢

4.1 核心表结构设计：5 张表讲清业务边界

校园系统的完整表可能有三四十张，但最能体现设计功力的就这 5 张：用户表（统一认证）、学生信息表、教师信息表、课程表和选课表。用户表只做认证，学生和教师表通过 user_id 关联用户表。这样设计的理由：一个教师同时是管理员或班主任时，不需要在两张表里各存一份密码。

CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录账号，学号或工号', `password` varchar(100) NOT NULL COMMENT 'BCrypt哈希后的密码', `role` tinyint(4) NOT NULL COMMENT '1-管理员 2-教师 3-学生', `status` tinyint(4) DEFAULT '1' COMMENT '1-启用 0-禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `deleted` tinyint(1) DEFAULT '0', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `course_select` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `course_id` bigint(20) NOT NULL, `student_id` bigint(20) NOT NULL, `select_time` datetime DEFAULT CURRENT_TIMESTAMP, `deleted` tinyint(1) DEFAULT '0', PRIMARY KEY (`id`), UNIQUE KEY `uk_course_student` (`course_id`, `student_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

course_select表上的联合唯一索引是必须的——就算应用层做了幂等，数据库层的约束依然是兜底。我是建议把所有表的deleted字段都加进唯一索引里，否则逻辑删除的数据会再次插入时撞唯一键。比如学生退选后 deleted=1，如果唯一索引只包含 course_id 和 student_id，他再选同一门课时 insert 会直接报 Duplicate Entry，这时候必须把 deleted 也放进唯一索引，或者退选改成物理删除。

4.2 分页查询慢的三个原因与对策

智慧校园的列表页（成绩列表、选课列表、考勤记录）都会遇到越翻越慢的问题。原因基本逃不出三个：大字段拖累查询、offset 翻页深、条件列无索引。

第一个问题最容易犯——用 MyBatis-Plus 的selectList查列表时，默认把大文本字段（如 notice 的 content、course 的 description）也查出来。正确做法是列表查询只 select 需要的列。第二个问题是深分页，LIMIT 100000, 10意味着 MySQL 要扫 100010 行，然后丢弃前 100000 行，代价非常大。常见做法是改成“前端传上一页最后一条记录的 ID，用WHERE id > lastId拿下一页”，这种 keyset 分页法在千万级数据下几乎恒定快。第三个问题最隐蔽，多条件组合查询时，条件列如果没有联合索引，MySQL 可能放弃索引做全表扫描。

// 列表查询只查必要字段，不要直接 selectList 整个实体 IPage<CourseVO> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Course> wrapper = new LambdaQueryWrapper<>(); wrapper.select(Course::getId, Course::getName, Course::getTeacherId, Course::getCapacity, Course::getSelectedCount) .eq(StringUtils.isNotBlank(teacherName), Course::getTeacherName, teacherName) .orderByDesc(Course::getCreateTime); courseMapper.selectPage(page, wrapper);

配套的 SQL 优化手段还有三个：一是给create_time加索引，排序列有索引能避免 filesort；二是给外键列（teacher_id、class_id、major_id）都建上普通索引，InnoDB 不会自动为外键建索引；三是用EXPLAIN查看执行计划，注意 type 能不能到 range 或 ref，Extra 里有没有 Using filesort 和 Using temporary。

4.3 逻辑删除与唯一索引冲突的处理

这是绝大多数人做了逻辑删除之后一定会踩的坑。现象：用户删除后重新添加，报Duplicate entry '10001' for key 'uk_username'。原因：用户表的唯一索引建立在 username 上，第一条数据逻辑删除后记录依然存在，再次插入同 username 数据就撞索引了。解决思路通常有三种。

第一种，把 deleted 字段改成“删除时间戳”，删除时写当前时间戳而不是 1，唯一索引改成(username, deleted)，这样每次删除后的记录 deleted 值都不同，不会撞索引。第二种，删除时把 username 改成一个带随机后缀的值，比如username + '_deleted_' + UUID，缺点是要额外处理校验逻辑。第三种，如果项目对“已删除数据可恢复”诉求不强，直接物理删除。对于智慧校园系统，我一般推荐第二种，因为第一种方案会让所有查询都带上deleted = 0条件，MyBatis-Plus 的@TableLogic会自动追加，但手动写 SQL 或联表查询时很容易忘。

5. 避坑 / 常见问题 / 排查：部署与运行阶段的 6 个经典翻车现场

5.1 打包后前端页面全白，接口却能通

现象：把 Vue 打包的 dist 文件夹放进 SpringBoot 的 static 目录后，访问首页白屏，但 /api 接口通过 Postman 调是通的。原因：Vue 使用的是 history 路由模式，页面跳转时 URL 路径是 /course，后端没有这个路径的映射，返回 404，前端拿到 404 就白屏了。

解决：后端加一个 fallback 控制器，对所有非 /api 开头的请求都转发到 index.html。注意 SpringBoot 3 的写法是PathPatternParser，如果你用 2.7 版本，用下面这个ViewControllerRegistry方法最省事：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController("/{path:[^\\.]*}") .setViewName("forward:/index.html"); } }

5.2 页面报 401 但登录接口没问题，拦截器把静态资源也拦了

现象：项目启动后，访问/doc.html或/static/js/app.js全部返回 401。原因：拦截器配置时只排除了登录接口，没排除静态资源。解决：把静态资源路径也加进排除列表，或者更稳妥的做法是，拦截器里先判断请求 URI 是否包含.js、.css、.png、.html等后缀，包含就直接放行。

5.3Invalid bound statement (not found)报错

现象：调用某张表的 BaseMapper 方法时，提醒Invalid bound statement。原因：Mapper 接口没有被扫描到，或者 XML 文件没有打包进 target/classes。解决：检查启动类上是否有@MapperScan("com.school.smartcampus.mapper")，以及 pom.xml 里是否配置了 Maven 打包时包含**/mapper/*.xml。最常被忽略的是第二种——MyBatis-Plus 的纯注解方式不需要 XML，但一旦某天你在 resources 里放了 XML，就必须加这个配置，否则本地跑得通、打包后必挂。

5.4 中文乱码，数据库里也是乱码

现象：接口返回的 JSON 中文正常，但写入 MySQL 变成???。原因：数据库连接串没指定 utf8mb4，或数据库表的字符集没建对。解决：JDBC 连接串末尾加useUnicode=true&characterEncoding=utf8mb4，建库语句写CREATE DATABASE school DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci。注意一个细节——连接串里的serverTimezone也建议加，不如直接写Asia/Shanghai，否则本地时间比实际早 8 小时，Redis 和数据库的时间戳对不上，日志排查时会鬼打墙。

5.5 Bean 冲突：多个 DataSource 或 RedisTemplate 注入失败

现象：项目一启动就报No qualifying bean of type 'StringRedisTemplate'，或者The bean 'xxx' could not be registered。原因：引入多个 SpringBoot starter 时自动配置冲突，或者配置了多个数据源没有指定主次。解决：如果同时引入spring-boot-starter-data-redis和某个自定义 Redis 配置类，删除自定义配置类，直接用 StringRedisTemplate；如果配置了多数据源，在其中一个配置类上加上@Primary注解。

5.6 打包后运行时提示端口被占用

现象：java -jar启动时报Web server failed to start. Port 8080 was already in use。原因：上次进程没杀掉或服务器上已有别的项目占用了端口。解决：一条命令快速查杀：

netstat -tlnp | grep 8080 kill -9 [PID] # 或者启动时临时改端口，不修改配置文件 java -jar school-0.0.1-SNAPSHOT.jar --server.port=8081

这类启动失败的问题，日志基本能告诉你 90% 的答案。教我排查习惯的老师傅说过一句话：先看日志最后 30 行，别再从头到尾扫一遍，这是最快定位问题的习惯。

6. 最后一步：把这套系统跑出“可演示”的效果，再做三个小优化

到这一步，你的系统已经有了完整模块，但“能跑”和“能演示、能答辩、能真正上线用”之间还有三个小差距。第一个是接口文档，务必引入 SpringDoc 依赖，启动项目后访问/doc.html，把所有接口的入参出参写清楚。这不仅是给前端看的，答辩时评委直接扫一眼文档页，对项目完成度的印象会直观很多。第二个是初始化数据，写一个CommandLineRunner实现类，在项目启动时自动创建管理员账号、导入几个班级和课程样例。我第一次给学校演示前忘了这回事，打开系统发现首页空空如也，那种尴尬不想经历第二次。第三个是验证慢 SQL 日志，在 application.yml 里开启 MyBatis-Plus 的 SQL 日志：

mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

把StdOutImpl换成Slf4jImpl就是生产环境的正确姿势——否则每个请求的 SQL 都会刷到控制台，日志文件一天能膨胀到几百 MB。

最后说个我的工作习惯。每次交付这种管理系统，我会把部署命令写成一个 start.sh 脚本放在项目根目录：检查 JDK 版本、检查端口占用、启动 Jar、打印日志路径。不要小看这个脚本，半年后客户叫你远程帮他重启，你隔着电话指导对方执行一行bash start.sh，比现场操作轻松太多了。技术方案本身没有多神秘，但你的工程习惯能决定这个系统是“能跑”还是“好维护”。希望这套从架构选型到排错思路的记录能帮你少走几趟弯路——至少，别在答辩前一天晚上还在调端口占用。

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