简介高校后勤管理中水电计费涉及大量宿舍、租户和月度数据传统手工抄表与Excel对账效率低、易出错。水电管理系统通过数字化手段实现“抄表—计费—缴费—统计”全链路线上化。以Spring Boot为核心框架结合MyBatis Plus与MySQL系统采用分层架构清晰划分控制层、业务层与数据层并通过JWT实现无状态认证和角色权限控制。数据库以房间为中心设计唯一约束和可配置阶梯计费规则确保费用计算准确且灵活。系统可广泛应用于大学城多校区、多楼栋场景支持管理员批量生成账单、学生在线缴费及数据统计为高校后勤提供稳定可靠的一体化解决方案。本文从业务场景到核心实现详细解析该系统设计的关键技术细节。1. 项目整体解构一套大学城水电系统到底包含什么1.1 核心需求与业务场景分析先把这个项目的定位说清楚。基于Spring Boot的大学城水电管理系统说白了就是给高校后勤/物业管理部门做的一套水电业务数字化工具。高校场景下宿舍楼多、租户多、人员流动性大水电管理如果还靠Excel表格和纸质单据一到月底对账就变成一场灾难。这个系统的核心价值就是把“抄表—计费—缴费—统计”这条链路全部线上化。从业务场景来看用户角色可以分两类一类是管理员负责楼栋管理、房间管理、抄表录入、查看缴费情况另一类是学生或租户负责查看自己房间的用水用电量、生成账单、在线缴费、查历史记录。这里的“大学城”其实不只是单个学校可能包含多个校区、多所高校的公寓片区所以楼栋和组织架构要支持多层级。实际做这类系统时最容易踩的坑是“需求边界不清”。我见过不少同学把系统设计得特别庞大加了报修、公告、投诉、二手交易之类的模块结果核心的水电计费逻辑写得稀碎。一个能通过答辩、能上线运行的水电管理系统核心永远是数据录入可靠、计费规则清晰、账单查询方便、权限控制得当。花里胡哨的功能都是锦上添花基础链路才是根基。1.2 功能模块划分与设计思路一个完整的水电管理系统按角色拆分后通常包含以下模块用户管理管理员账号、学生/租户账号的注册、登录、角色权限管理楼栋与房间管理维护校区、楼栋、楼层、房间的层级关系支持房间状态变更水电表管理每个房间绑定独立的水表和电表记录表编号、初始读数、所在位置抄表管理管理员按月份录入水表读数和电表读数系统自动计算本期用量费用计算根据用量、单价、阶梯价格规则自动生成应收费用账单管理生成月度账单支持在线缴费、缴费记录查询、欠费提醒数据统计按楼栋、按月统计用水用电总量和费用支持图表展示设计思路上有几个关键决策点值得展开说。第一为什么不直接用一个“总表分摊”的模式因为大学城场景下每个房间独立计费才是常态总表分摊只适用于公共区域。所以数据模型必须做到“一房一表”最好是水电分开两张表记录避免混在一起导致后续统计困难。第二月度抄表记录要做唯一性约束。也就是说同一房间同一个月只能有一条水表读数和一条电表读数录入时后端必须校验否则会造成费用重复计算。这个约束我在数据库层面用唯一索引实现应用层再做二次校验双保险。第三计费规则要可配置。不同高校的收费标准不同有的按阶梯电价有的按固定单价有的还有热水冷水之分。所以单价和阶梯规则不能写死在代码里要放到数据库或者配置文件中管理员能自行调整。2. 技术选型与工程结构说明2.1 为什么是Spring Boot MyBatis Plus MySQL这套技术栈在2024年依然是Java后端毕业设计和工作项目的绝对主流没有之一。Spring Boot负责快速搭建应用骨架内嵌Tomcat省去了一大堆XML配置MyBatis Plus在MyBatis基础上封装了通用CRUD写简单的增删改查基本不用手写SQLMySQL做持久化存储完全够用。可能有同学会问为什么不选Spring Cloud说实话大学城水电管理系统这类单体应用业务量级远没到需要微服务拆分的地步。如果强行引入Spring Cloud服务注册、配置中心、网关这些组件会占用大量开发时间而且对JVM内存的要求也更高本地跑起来都费劲。单体的Spring Boot应用把代码结构理清楚后期真要扩展按模块拆服务也不难。技术选型最重要的是匹配业务复杂度不是追新。前端方面配套源码里通常有两种方案一种是纯后端渲染用Thymeleaf模板另一种是前后端分离Spring Boot提供JSON接口前端用Vue或Layui实现页面。如果项目是“源码论文”的形式我建议前端用Layui或者Bootstrap这类轻量方案因为Layui对后端开发者非常友好引入静态文件就能用表格、表单、弹窗组件全都有不需要单独搭Node环境论文里也好写。Vue前后端分离虽然更现代但对只关注后端的同学来说联调成本和部署复杂度都会高一些。2.2 项目目录结构与分层思想拿到源码之后第一步不是急着跑起来而是先把目录结构看懂。标准的Spring Boot多模块或单模块分层结构通常长这样university-water-electricity/ ├── src/main/java │ └── com/example/wes │ ├── controller/ # 接口层接收请求、返回结果 │ ├── service/ # 业务层核心逻辑都在这 │ │ └── impl/ # 业务实现类 │ ├── mapper/ # 数据访问层MyBatis Plus的Mapper接口 │ ├── entity/ # 实体类对应数据库表 │ ├── dto/ # 数据传输对象接收前端参数 │ ├── vo/ # 视图对象返回给前端的数据 │ ├── config/ # 配置类比如MyBatis Plus分页插件 │ ├── common/ # 公共类统一返回结果、异常处理 │ └── utils/ # 工具类JWT工具、日期工具等 ├── src/main/resources │ ├── mapper/ # XML形式的SQL映射文件非必须 │ ├── application.yml # 核心配置文件 │ └── sql/ # 数据库初始化脚本 └── pom.xml # Maven依赖管理这里想特别强调分层的意义Controller只做参数接收和结果封装不写业务逻辑Service层负责具体业务比如费用计算、状态流转Mapper层只跟数据库打交道。这样分的好处是出问题的时候能快速定位也方便写单元测试。做毕业设计时论文里的“系统设计”章节可以直接把这套分层架构画成图非常加分。我第一次做这种项目的时候曾把查询SQL直接写在Controller里后来需求一改连我自己都看不懂自己写的代码。分层这事看着麻烦实际上是在给自己省事。3. 数据库设计与核心表结构3.1 核心表设计与字段解析数据库是整个系统的地基表结构设计得好不好直接决定后续开发的顺畅程度。这套系统最核心的表有六张我逐一说明设计要点。用户表sys_user字段名类型说明idbigint主键自增usernamevarchar(50)登录名唯一passwordvarchar(100)加密后的密码BCryptreal_namevarchar(50)真实姓名roletinyint角色1-管理员2-学生/租户phonevarchar(20)手机号room_idbigint关联房间表仅租户有statustinyint状态0-禁用1-正常create_timedatetime创建时间密码存储这块必须用BCrypt加密不要用MD5。MD5虽然也能用但彩虹表攻击一下就能还原而且Spring Security的BCryptPasswordEncoder本身就集成在Spring Boot生态里两行代码搞定没有理由不用。楼栋表building字段包括id、name、campus、floors楼层数、sort排序。房间表room字段包括id、building_id、room_no、floor、area面积、capacity可住人数、status0-空闲1-已入住。这个status字段很关键学生入住和退宿时都要更新它也是楼栋空置率统计的数据来源。水电表记录表meter_record这张表是整个系统的数据核心字段名类型说明idbigint主键room_idbigint房间IDrecord_monthvarchar(7)账期格式yyyy-MMwater_previousdecimal(10,2)上月水表读数water_currentdecimal(10,2)本月水表读数electric_previousdecimal(10,2)上月电表读数electric_currentdecimal(10,2)本月电表读数water_usagedecimal(10,2)本月用水量计算得出electric_usagedecimal(10,2)本月用电量计算得出statustinyint0-未生成账单1-已生成账单create_timedatetime抄表时间账单表bill字段包括id、room_id、record_month、water_fee、electric_fee、total_fee、status0-未缴费1-已缴费、pay_time、pay_method。缴费记录表payment_record字段包括id、bill_id、user_id、amount、pay_time、trade_no支付流水号、pay_method。这六张表之间的关系并不复杂用户挂在房间下房间挂在楼栋下抄表记录和账单都挂在房间下缴费记录挂在账单下。设计核心是“以房间为中心”所有费用数据都能按房间号追溯到人。3.2 计费规则与表关联逻辑水电计费最核心的规则是阶梯计费。以电费为例很多高校采用阶梯电价每月用电量在X度以内的按0.55元/度超过部分按0.85元/度。这个规则要支持自定义所以在设计上我会单独建一张费用规则表charge_rule字段名类型说明idbigint主键typetinyint1-水费2-电费tier_startdecimal(10,2)阶梯起始用量tier_enddecimal(10,2)阶梯结束用量为空表示无上限pricedecimal(10,2)该阶梯单价effective_datedate生效日期查费用规则时按effective_date倒序取最新的一条生效规则。这个设计虽然多了一张表但灵活性很高。后续如果学校调整收费标准管理员在后台改一下规则就行代码一行都不用动。在实际开发中计费逻辑不要写在Controller里也不要散落在Service的各个方法中而是单独抽一个FeeCalculator工具类或者策略类。Spring Boot的Service注解天然支持策略注入接口定义calculate(List records)不同的实现类处理不同阶梯规则后期扩展也方便。4. 核心功能实现一用户认证与权限控制4.1 登录认证方案的决策过程用户认证方案我在项目里选了JWT而不是传统的Session。原因有三前后端分离架构下移动端和Web端共用一套认证逻辑Session的Cookie机制不太好跨端。JWT是无状态的服务端不需要保存会话信息水平扩展时不用考虑Session共享问题。JWT里可以携带用户ID、角色等少量信息后端在拦截器中解析token后可以直接拿到当前用户上下文。JWT的缺点也是明显的token一旦签发在过期之前无法主动失效。针对这个问题我在设计时把token的有效期设得短一些比如8小时同时处理了前端在token过期后的401跳转逻辑。对于大学城水电系统这个量级完全够用不需要引入Redis做黑名单机制。4.2 登录模块与角色鉴权的代码实现登录接口的核心逻辑很简单接收用户名和密码先查用户再用BCrypt校验密码通过后生成token返回PostMapping(/login) public Result login(RequestBody LoginDTO loginDTO) { // 1. 根据用户名查用户 SysUser user userService.getByUsername(loginDTO.getUsername()); if (user null) { return Result.error(用户不存在); } // 2. 校验密码 if (!BCrypt.checkpw(loginDTO.getPassword(), user.getPassword())) { return Result.error(密码错误); } // 3. 检查状态 if (user.getStatus() 0) { return Result.error(账号已被禁用); } // 4. 生成JWT String token JwtUtil.generateToken(user.getId(), user.getRole()); return Result.success(token); }这里有一个容易被忽视的细节查询用户时不要只查用户名和密码两个字段要把role、status、room_id一起查出来因为后面业务逻辑都要用。一次查询能解决的别拆成三次。权限控制方面我用Spring MVC的拦截器HandlerInterceptor实现没有引入Spring Security全家桶。因为毕业设计和中小型项目中一个拦截器足够完成路由级权限控制引入Spring Security反而增加配置复杂度。拦截器里做两件事校验token是否存在且合法校验当前请求的路径是否匹配用户角色。Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BusinessException(未登录); } Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims null) { throw new BusinessException(登录已过期); } // 将用户信息放入ThreadLocal或request attribute方便后续获取 request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; }配合一个简单的WebMvcConfigurer配置类把拦截器注册进去再配置好放行路径比如/login、/register、静态资源整个权限体系就完成了。管理员接口在Controller上通过RequireRole之类的自定义注解标记拦截器里读取注解校验角色。这种方式代码量小逻辑直白论文也好解释。写代码时有个体会拦截器中的异常一定要抛出去交给全局异常处理器统一包装不要让请求带着异常继续往下走。一开始我图省事在拦截器里直接response.getWriter().write()返回错误信息结果前端拿不到统一格式的返回体排查了半天。5. 核心功能实现二水电表读数与费用计算5.1 抄表流程与用量计算逻辑水电表读数的录入是整个系统中操作最频繁的功能。管理员的日常操作就是选楼栋、选房间、输入本月水表读数、本月电表读数系统自动算出用量。计算用量的逻辑不复杂关键在于“自动带出上月读数”减少管理员输入量。后端实现时根据room_id和record_month查上个月的meter_record把上月的current读出来作为本月的previous值。如果查不到上月记录说明是第一次抄表previous值可以设置为0或者手动输入。这里的边界情况要注意新生入住第一月水表可能不是从0开始所以必须允许管理员手动修改上月读数。用量计算的代码逻辑public BigDecimal calculateUsage(BigDecimal previous, BigDecimal current) { // 校验当前读数不能小于上月读数 if (current.compareTo(previous) 0) { throw new BusinessException(当前读数不能小于上次读数); } return current.subtract(previous); }这个校验必须有。我在测试阶段就遇到过一次管理员录入时把“5.35”输成了“53.5”直接导致费用暴涨学生在系统里炸了锅。校验虽然简单但能从源头拦住大部分人为错误。另外水表和电表的读数建议分开录入不要放在同一个表单里因为实际抄表时水表在卫生间、电表在走廊管理员是分两次抄的。5.2 阶梯计费算法的设计与实现计费算法是系统的核心我把代码贴出来详细说一下。以阶梯电费为例Service public class FeeCalculateServiceImpl implements FeeCalculateService { Override public BigDecimal calElectricFee(BigDecimal usage, LocalDate billDate) { // 查询当前生效的电费阶梯规则 ListChargeRule rules chargeRuleMapper.getActiveRules(2, billDate); if (rules.isEmpty()) { throw new BusinessException(未配置电费收费规则); } BigDecimal totalFee BigDecimal.ZERO; BigDecimal remaining usage; for (ChargeRule rule : rules) { if (remaining.compareTo(BigDecimal.ZERO) 0) { break; } // 计算本阶梯的可用量 BigDecimal tierLimit rule.getTierEnd() null ? remaining : rule.getTierEnd().subtract(rule.getTierStart()).add(BigDecimal.ONE); BigDecimal usedInTier remaining.min(tierLimit); // 累加费用保留两位小数 totalFee totalFee.add(usedInTier.multiply(rule.getPrice())) .setScale(2, RoundingMode.HALF_UP); remaining remaining.subtract(usedInTier); } return totalFee; } }这个算法的思路是把每个阶梯想象成一个“容量有限的水桶”用户用量先填第一档填满了再流进第二档以此类推。用remaining记录还没有被计费的用量每进入一个阶梯就消耗一部分。边界情况是最后一档tierEnd为null表示上不封顶直接把remaining乘以单价即可。为什么用BigDecimal而不是double因为double在计算小数时会丢失精度0.1 0.2都会出现误差。金额计算类的场景必须用BigDecimal这是Java开发的铁律。在代码中我还用了RoundingMode.HALF_UP也就是四舍五入避免金额出现超长小数。水费计算逻辑和电费完全一致只是rule.getType()不同。把费用计算抽成独立服务后后面在做批量生成账单时只需要循环房间列表一个个调用计费服务就行代码非常干净。6. 核心功能实现三缴费与账单管理6.1 月度账单的生成策略账单不能实时生成而是采用“月度批量生成”策略。月末抄表完成后管理员点击“生成当月账单”按钮后端遍历所有有抄表记录的房间计算费用生成账单记录。这里要考虑一个重复生成问题。如果管理员误操作点了两次“生成账单”同一月份同一房间就会生成两条账单。我的解决方案是在meter_record表上加一个status字段抄表录入后status为0生成账单后置为1。生成账单的接口只处理status0的抄表记录处理完立即更新状态。同时在bill表上加唯一索引(room_id, record_month)数据库层面兜底双保险确保不会重复。批量生成的伪代码如下Transactional public void generateMonthlyBills(String month) { // 1. 查询所有未生成账单的抄表记录 ListMeterRecord records meterRecordMapper.getUnbilledRecords(month); for (MeterRecord record : records) { // 2. 计算水电费用 BigDecimal waterFee feeCalculateService.calWaterFee(record.getWaterUsage(), month); BigDecimal electricFee feeCalculateService.calElectricFee(record.getElectricUsage(), month); // 3. 创建账单 Bill bill new Bill(); bill.setRoomId(record.getRoomId()); bill.setRecordMonth(month); bill.setWaterFee(waterFee); bill.setElectricFee(electricFee); bill.setTotalFee(waterFee.add(electricFee)); bill.setStatus(0); billMapper.insert(bill); // 4. 更新抄表记录状态 record.setStatus(1); meterRecordMapper.updateById(record); } }看到Transactional注解了吗这个方法必须在事务中执行否则中途某个房间计算失败前面的房间已经生成了账单后面的房间却还是待生成状态数据就不一致了。加了事务之后任何一个房间失败整批操作全部回滚。这是生产环境级别的严谨性论文里写出来也是加分项。6.2 缴费流程与数据状态流转在线缴费流程要区分“模拟支付”和“真实支付”。毕业设计通常没有对接支付宝或微信支付的资质所以源码里通常用的是模拟支付学生点击“去缴费”系统生成一笔缴费记录状态置为已支付更新账单状态。如果要做得更有说服力可以在缴费页面展示一个“二维码”图片可以随便放然后提供一个“模拟支付成功”的按钮等于是演示了完整流程。缴费成功后账单状态从0未缴费变为1已缴费同时写入payment_record表。用户查询账单列表时能清晰看到每个月的费用明细和交费状态。这里要关注一个细节账单和缴费记录建立关联之后不能允许同一张账单重复缴费。我给bill表加了status判断只有status0的账单才能发起缴费支付成功后先更新账单状态再插入缴费记录两步操作放在同一个事务里。这样即使并发请求打过来也最多只有一笔操作能成功。统计报表方面按楼栋汇总月用电量、按学院汇总欠费金额、按学期对比用水量这些SQL都相对简单但输出格式要做统一封装。我通常会定义一个DashboardVO把总房间数、已入住数、本月用水总量、本月用电总量、本月应收总费用、已缴费用、欠费金额这些聚合数据一次性返回给前端。前端就能直接渲染成一个数据看板视觉效果和专业度都拉满论文里的“系统测试”章节也用得上。7. 系统部署与论文写作的实战经验7.1 本地环境搭建与快速启动指南拿到源码后最快的启动步骤是“三步法”初始化数据库用Navicat或命令行执行sql目录下的init.sql脚本创建数据库和表结构。修改配置文件打开application.yml改数据库连接的用户名和密码。有些项目的数据库账号不是root或者MySQL端口不是3306这些都要改成自己的环境。启动项目用IDEA打开项目等待Maven下载完依赖找到主启动类右键Run。看到“Started ... in xxx seconds”的日志就说明启动成功了。这里有个高频问题Maven依赖下载不下来或者下载速度极慢。解决方案是修改Maven的settings.xml把镜像仓库换成阿里云的mirror。这不是教程里会写的东西但几乎所有新手实战时都会卡在这。换完镜像后依赖基本秒下。启动成功后先别急着登录系统用Postman或者浏览器直接访问一下接口文档地址确认后端是通的。如果项目集成了Swagger访问/swagger-ui/index.html就能看到所有接口和参数说明这个页面不仅方便调试写论文时截图也是很好的素材。7.2 论文撰写的逻辑主线与图表建议这篇论文的写作逻辑建议按“发现问题—分析问题—解决问题—验证结果”四段式展开。背景部分强调传统水电管理的痛点手工抄表效率低、数据不透明、费用计算容易出错、学生缴费不方便。技术选型部分重点解释为什么选Spring Boot而不是简单罗列技术名称——因为Spring Boot简化了项目搭建和配置内置Tomcat让部署变得容易生态丰富方便集成其他组件。系统设计章节建议画三张图一是系统总体架构图展示前端、后端、数据库的层次关系二是功能模块图用树状图展示系统的功能结构三是数据库ER图把六张核心表以及它们之间的关系画清楚。这三张图是论文的骨架有了它们内容就顺理成章。代码实现章节不必把源码全部贴上去选三个核心功能的代码即可登录鉴权的核心代码、费用计算的算法代码、批量生成账单的代码。每个代码块后配上两三段解释说明设计思路和实现细节。我发现不少论文的代码是纯堆砌没有任何解释这其实很吃亏——评委想看到的是你理解这段代码而不是复制粘贴。测试章节用表格展示测试用例比如正常缴费流程、重复账单生成、阶梯计费边界等表格说清楚输入、预期输出、实际输出和结论。8. 常见问题与避坑指南8.1 启动与运行阶段的经典故障这个项目跑起来的时候最常见的坑基本集中在几个地方数据库连接失败。报错一般是“Access denied for user”或者“Communications link failure”。前者是账号密码错了后者是MySQL没启动或者端口不对。遇到这种报错先ping一下数据库再用命令行登录试试逐层排查。有一点务必确认MySQL 8.x的驱动类名是com.mysql.cj.jdbc.Driver在pom.xml中引入mysql-connector-java时要注意版本兼容性推荐用8.0.33。项目端口被占用。默认端口8080如果本机装了其他服务占用了8080启动会直接报错。最简单的处理方式是改配置文件里的server.port为8081、9090等不常用的端口。这个坑在答辩现场特别常见我记得有个同学答辩前两小时发现端口被占用当时慌得不行。MyBatis Plus表名映射问题。数据库表名是sys_user实体类名是SysUserMyBatis Plus默认的驼峰转下划线规则可以正常映射。但如果你给实体类起名UserMyBatis Plus会在数据库中找user表如果你的表叫sys_user就会报表不存在的错误。解决方案是在实体类上加TableName(sys_user)注解一劳永逸。8.2 从能跑到能讲的细节优化源码能跑只是第一步答辩时能讲清楚才是关键。我建议拿到任何源码后做三件事第一把项目的数据库初始化脚本完整执行一遍然后自己手动插入几条测试数据熟悉表结构。尤其是用户表里的角色字段管理员账号和普通学生账号的数据要清楚哪个账号是管理员、哪个是学生面试官问起来要能脱口而出。第二跑通一遍完整业务流程管理员登录→录入抄表→生成账单→学生登录→查看账单→缴费→管理员查看统计报表。走完这个流程你就对系统有了全貌性的理解任何功能的代码在哪、数据存在哪张表、状态如何流转心里都有一张地图。第三主动改一两个小功能练手。比如把系统中的水费单价从固定值改成可配置的阶梯计费或者给账单列表加一个导出Excel功能。改代码的过程会迫使你真正理解原有代码的设计逻辑这是从“会跑”到“会讲”的关键一步。有些同学答辩时被问代码细节就卡壳就是因为只看过没改过说到深层就露馅了。8.3 功能扩展的四个方向如果这套系统做完还有富裕时间我建议挑一两个方向扩展。比较实用的扩展方向包括对接微信公众号或企业微信学生绑定房间后每月账单自动推送提醒欠费也能收到通知增加微信支付/支付宝支付的模拟沙箱对接把缴费流程做成真实的支付链路引入定时任务框架如Spring Task或Quartz每月1号自动生成本月账单减少管理员手动操作增加报修功能学生可以在线提交水管漏水、电灯损坏的工单物业后台接单处理形成“水电管理维修服务”的闭环我当时给一个学弟的建议是优先做定时任务因为成本最低、代码量小、演示效果直观。在Spring Boot主类上加EnableScheduling注解然后写一个Component修饰的定时任务方法用Scheduled(cron 0 0 0 1 * ?)每月1号零点触发批量生成账单逻辑。这段代码不到30行但答辩时能讲清楚定时任务的原理就是很大的亮点。从我个人的经验来看做这类管理系统的毕业设计真正的难点从来不是某个技术点有多难而是能不能把业务逻辑理清楚再把代码组织得有层次感。Spring Boot把框架层面的复杂度降低了很多剩下的核心就在于业务建模和细节处理上。多看几遍源码里实体类和数据表之间的对应关系多跑几遍完整流程多改几个功能试试这个项目就能真正变成你自己的东西。最后再分享一个小技巧去答辩前一定要在干净环境重新部署一次项目也就是把数据库删掉重新执行init.sql把IDEA的缓存清一下然后完整启动一遍。这么做的目的不是检查代码能不能跑而是让你记住整个部署过程里有哪些坑熟悉到闭着眼睛都能解决。答辩现场环境跟开发环境基本不一样谁能快速解决部署问题谁就掌握了主动。本文还有配套的精品资源点击获取 
长河君 · 2026/8/29 18:50:44 · 阅读 1.2k Spring Boot大学城水电管理系统：从架构设计到核心实现
简介高校后勤管理中水电计费涉及大量宿舍、租户和月度数据传统手工抄表与Excel对账效率低、易出错。水电管理系统通过数字化手段实现“抄表—计费—缴费—统计”全链路线上化。以Spring Boot为核心框架结合MyBatis Plus与MySQL系统采用分层架构清晰划分控制层、业务层与数据层并通过JWT实现无状态认证和角色权限控制。数据库以房间为中心设计唯一约束和可配置阶梯计费规则确保费用计算准确且灵活。系统可广泛应用于大学城多校区、多楼栋场景支持管理员批量生成账单、学生在线缴费及数据统计为高校后勤提供稳定可靠的一体化解决方案。本文从业务场景到核心实现详细解析该系统设计的关键技术细节。1. 项目整体解构一套大学城水电系统到底包含什么1.1 核心需求与业务场景分析先把这个项目的定位说清楚。基于Spring Boot的大学城水电管理系统说白了就是给高校后勤/物业管理部门做的一套水电业务数字化工具。高校场景下宿舍楼多、租户多、人员流动性大水电管理如果还靠Excel表格和纸质单据一到月底对账就变成一场灾难。这个系统的核心价值就是把“抄表—计费—缴费—统计”这条链路全部线上化。从业务场景来看用户角色可以分两类一类是管理员负责楼栋管理、房间管理、抄表录入、查看缴费情况另一类是学生或租户负责查看自己房间的用水用电量、生成账单、在线缴费、查历史记录。这里的“大学城”其实不只是单个学校可能包含多个校区、多所高校的公寓片区所以楼栋和组织架构要支持多层级。实际做这类系统时最容易踩的坑是“需求边界不清”。我见过不少同学把系统设计得特别庞大加了报修、公告、投诉、二手交易之类的模块结果核心的水电计费逻辑写得稀碎。一个能通过答辩、能上线运行的水电管理系统核心永远是数据录入可靠、计费规则清晰、账单查询方便、权限控制得当。花里胡哨的功能都是锦上添花基础链路才是根基。1.2 功能模块划分与设计思路一个完整的水电管理系统按角色拆分后通常包含以下模块用户管理管理员账号、学生/租户账号的注册、登录、角色权限管理楼栋与房间管理维护校区、楼栋、楼层、房间的层级关系支持房间状态变更水电表管理每个房间绑定独立的水表和电表记录表编号、初始读数、所在位置抄表管理管理员按月份录入水表读数和电表读数系统自动计算本期用量费用计算根据用量、单价、阶梯价格规则自动生成应收费用账单管理生成月度账单支持在线缴费、缴费记录查询、欠费提醒数据统计按楼栋、按月统计用水用电总量和费用支持图表展示设计思路上有几个关键决策点值得展开说。第一为什么不直接用一个“总表分摊”的模式因为大学城场景下每个房间独立计费才是常态总表分摊只适用于公共区域。所以数据模型必须做到“一房一表”最好是水电分开两张表记录避免混在一起导致后续统计困难。第二月度抄表记录要做唯一性约束。也就是说同一房间同一个月只能有一条水表读数和一条电表读数录入时后端必须校验否则会造成费用重复计算。这个约束我在数据库层面用唯一索引实现应用层再做二次校验双保险。第三计费规则要可配置。不同高校的收费标准不同有的按阶梯电价有的按固定单价有的还有热水冷水之分。所以单价和阶梯规则不能写死在代码里要放到数据库或者配置文件中管理员能自行调整。2. 技术选型与工程结构说明2.1 为什么是Spring Boot MyBatis Plus MySQL这套技术栈在2024年依然是Java后端毕业设计和工作项目的绝对主流没有之一。Spring Boot负责快速搭建应用骨架内嵌Tomcat省去了一大堆XML配置MyBatis Plus在MyBatis基础上封装了通用CRUD写简单的增删改查基本不用手写SQLMySQL做持久化存储完全够用。可能有同学会问为什么不选Spring Cloud说实话大学城水电管理系统这类单体应用业务量级远没到需要微服务拆分的地步。如果强行引入Spring Cloud服务注册、配置中心、网关这些组件会占用大量开发时间而且对JVM内存的要求也更高本地跑起来都费劲。单体的Spring Boot应用把代码结构理清楚后期真要扩展按模块拆服务也不难。技术选型最重要的是匹配业务复杂度不是追新。前端方面配套源码里通常有两种方案一种是纯后端渲染用Thymeleaf模板另一种是前后端分离Spring Boot提供JSON接口前端用Vue或Layui实现页面。如果项目是“源码论文”的形式我建议前端用Layui或者Bootstrap这类轻量方案因为Layui对后端开发者非常友好引入静态文件就能用表格、表单、弹窗组件全都有不需要单独搭Node环境论文里也好写。Vue前后端分离虽然更现代但对只关注后端的同学来说联调成本和部署复杂度都会高一些。2.2 项目目录结构与分层思想拿到源码之后第一步不是急着跑起来而是先把目录结构看懂。标准的Spring Boot多模块或单模块分层结构通常长这样university-water-electricity/ ├── src/main/java │ └── com/example/wes │ ├── controller/ # 接口层接收请求、返回结果 │ ├── service/ # 业务层核心逻辑都在这 │ │ └── impl/ # 业务实现类 │ ├── mapper/ # 数据访问层MyBatis Plus的Mapper接口 │ ├── entity/ # 实体类对应数据库表 │ ├── dto/ # 数据传输对象接收前端参数 │ ├── vo/ # 视图对象返回给前端的数据 │ ├── config/ # 配置类比如MyBatis Plus分页插件 │ ├── common/ # 公共类统一返回结果、异常处理 │ └── utils/ # 工具类JWT工具、日期工具等 ├── src/main/resources │ ├── mapper/ # XML形式的SQL映射文件非必须 │ ├── application.yml # 核心配置文件 │ └── sql/ # 数据库初始化脚本 └── pom.xml # Maven依赖管理这里想特别强调分层的意义Controller只做参数接收和结果封装不写业务逻辑Service层负责具体业务比如费用计算、状态流转Mapper层只跟数据库打交道。这样分的好处是出问题的时候能快速定位也方便写单元测试。做毕业设计时论文里的“系统设计”章节可以直接把这套分层架构画成图非常加分。我第一次做这种项目的时候曾把查询SQL直接写在Controller里后来需求一改连我自己都看不懂自己写的代码。分层这事看着麻烦实际上是在给自己省事。3. 数据库设计与核心表结构3.1 核心表设计与字段解析数据库是整个系统的地基表结构设计得好不好直接决定后续开发的顺畅程度。这套系统最核心的表有六张我逐一说明设计要点。用户表sys_user字段名类型说明idbigint主键自增usernamevarchar(50)登录名唯一passwordvarchar(100)加密后的密码BCryptreal_namevarchar(50)真实姓名roletinyint角色1-管理员2-学生/租户phonevarchar(20)手机号room_idbigint关联房间表仅租户有statustinyint状态0-禁用1-正常create_timedatetime创建时间密码存储这块必须用BCrypt加密不要用MD5。MD5虽然也能用但彩虹表攻击一下就能还原而且Spring Security的BCryptPasswordEncoder本身就集成在Spring Boot生态里两行代码搞定没有理由不用。楼栋表building字段包括id、name、campus、floors楼层数、sort排序。房间表room字段包括id、building_id、room_no、floor、area面积、capacity可住人数、status0-空闲1-已入住。这个status字段很关键学生入住和退宿时都要更新它也是楼栋空置率统计的数据来源。水电表记录表meter_record这张表是整个系统的数据核心字段名类型说明idbigint主键room_idbigint房间IDrecord_monthvarchar(7)账期格式yyyy-MMwater_previousdecimal(10,2)上月水表读数water_currentdecimal(10,2)本月水表读数electric_previousdecimal(10,2)上月电表读数electric_currentdecimal(10,2)本月电表读数water_usagedecimal(10,2)本月用水量计算得出electric_usagedecimal(10,2)本月用电量计算得出statustinyint0-未生成账单1-已生成账单create_timedatetime抄表时间账单表bill字段包括id、room_id、record_month、water_fee、electric_fee、total_fee、status0-未缴费1-已缴费、pay_time、pay_method。缴费记录表payment_record字段包括id、bill_id、user_id、amount、pay_time、trade_no支付流水号、pay_method。这六张表之间的关系并不复杂用户挂在房间下房间挂在楼栋下抄表记录和账单都挂在房间下缴费记录挂在账单下。设计核心是“以房间为中心”所有费用数据都能按房间号追溯到人。3.2 计费规则与表关联逻辑水电计费最核心的规则是阶梯计费。以电费为例很多高校采用阶梯电价每月用电量在X度以内的按0.55元/度超过部分按0.85元/度。这个规则要支持自定义所以在设计上我会单独建一张费用规则表charge_rule字段名类型说明idbigint主键typetinyint1-水费2-电费tier_startdecimal(10,2)阶梯起始用量tier_enddecimal(10,2)阶梯结束用量为空表示无上限pricedecimal(10,2)该阶梯单价effective_datedate生效日期查费用规则时按effective_date倒序取最新的一条生效规则。这个设计虽然多了一张表但灵活性很高。后续如果学校调整收费标准管理员在后台改一下规则就行代码一行都不用动。在实际开发中计费逻辑不要写在Controller里也不要散落在Service的各个方法中而是单独抽一个FeeCalculator工具类或者策略类。Spring Boot的Service注解天然支持策略注入接口定义calculate(List records)不同的实现类处理不同阶梯规则后期扩展也方便。4. 核心功能实现一用户认证与权限控制4.1 登录认证方案的决策过程用户认证方案我在项目里选了JWT而不是传统的Session。原因有三前后端分离架构下移动端和Web端共用一套认证逻辑Session的Cookie机制不太好跨端。JWT是无状态的服务端不需要保存会话信息水平扩展时不用考虑Session共享问题。JWT里可以携带用户ID、角色等少量信息后端在拦截器中解析token后可以直接拿到当前用户上下文。JWT的缺点也是明显的token一旦签发在过期之前无法主动失效。针对这个问题我在设计时把token的有效期设得短一些比如8小时同时处理了前端在token过期后的401跳转逻辑。对于大学城水电系统这个量级完全够用不需要引入Redis做黑名单机制。4.2 登录模块与角色鉴权的代码实现登录接口的核心逻辑很简单接收用户名和密码先查用户再用BCrypt校验密码通过后生成token返回PostMapping(/login) public Result login(RequestBody LoginDTO loginDTO) { // 1. 根据用户名查用户 SysUser user userService.getByUsername(loginDTO.getUsername()); if (user null) { return Result.error(用户不存在); } // 2. 校验密码 if (!BCrypt.checkpw(loginDTO.getPassword(), user.getPassword())) { return Result.error(密码错误); } // 3. 检查状态 if (user.getStatus() 0) { return Result.error(账号已被禁用); } // 4. 生成JWT String token JwtUtil.generateToken(user.getId(), user.getRole()); return Result.success(token); }这里有一个容易被忽视的细节查询用户时不要只查用户名和密码两个字段要把role、status、room_id一起查出来因为后面业务逻辑都要用。一次查询能解决的别拆成三次。权限控制方面我用Spring MVC的拦截器HandlerInterceptor实现没有引入Spring Security全家桶。因为毕业设计和中小型项目中一个拦截器足够完成路由级权限控制引入Spring Security反而增加配置复杂度。拦截器里做两件事校验token是否存在且合法校验当前请求的路径是否匹配用户角色。Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BusinessException(未登录); } Claims claims JwtUtil.parseToken(token.replace(Bearer , )); if (claims null) { throw new BusinessException(登录已过期); } // 将用户信息放入ThreadLocal或request attribute方便后续获取 request.setAttribute(userId, claims.get(userId)); request.setAttribute(role, claims.get(role)); return true; }配合一个简单的WebMvcConfigurer配置类把拦截器注册进去再配置好放行路径比如/login、/register、静态资源整个权限体系就完成了。管理员接口在Controller上通过RequireRole之类的自定义注解标记拦截器里读取注解校验角色。这种方式代码量小逻辑直白论文也好解释。写代码时有个体会拦截器中的异常一定要抛出去交给全局异常处理器统一包装不要让请求带着异常继续往下走。一开始我图省事在拦截器里直接response.getWriter().write()返回错误信息结果前端拿不到统一格式的返回体排查了半天。5. 核心功能实现二水电表读数与费用计算5.1 抄表流程与用量计算逻辑水电表读数的录入是整个系统中操作最频繁的功能。管理员的日常操作就是选楼栋、选房间、输入本月水表读数、本月电表读数系统自动算出用量。计算用量的逻辑不复杂关键在于“自动带出上月读数”减少管理员输入量。后端实现时根据room_id和record_month查上个月的meter_record把上月的current读出来作为本月的previous值。如果查不到上月记录说明是第一次抄表previous值可以设置为0或者手动输入。这里的边界情况要注意新生入住第一月水表可能不是从0开始所以必须允许管理员手动修改上月读数。用量计算的代码逻辑public BigDecimal calculateUsage(BigDecimal previous, BigDecimal current) { // 校验当前读数不能小于上月读数 if (current.compareTo(previous) 0) { throw new BusinessException(当前读数不能小于上次读数); } return current.subtract(previous); }这个校验必须有。我在测试阶段就遇到过一次管理员录入时把“5.35”输成了“53.5”直接导致费用暴涨学生在系统里炸了锅。校验虽然简单但能从源头拦住大部分人为错误。另外水表和电表的读数建议分开录入不要放在同一个表单里因为实际抄表时水表在卫生间、电表在走廊管理员是分两次抄的。5.2 阶梯计费算法的设计与实现计费算法是系统的核心我把代码贴出来详细说一下。以阶梯电费为例Service public class FeeCalculateServiceImpl implements FeeCalculateService { Override public BigDecimal calElectricFee(BigDecimal usage, LocalDate billDate) { // 查询当前生效的电费阶梯规则 ListChargeRule rules chargeRuleMapper.getActiveRules(2, billDate); if (rules.isEmpty()) { throw new BusinessException(未配置电费收费规则); } BigDecimal totalFee BigDecimal.ZERO; BigDecimal remaining usage; for (ChargeRule rule : rules) { if (remaining.compareTo(BigDecimal.ZERO) 0) { break; } // 计算本阶梯的可用量 BigDecimal tierLimit rule.getTierEnd() null ? remaining : rule.getTierEnd().subtract(rule.getTierStart()).add(BigDecimal.ONE); BigDecimal usedInTier remaining.min(tierLimit); // 累加费用保留两位小数 totalFee totalFee.add(usedInTier.multiply(rule.getPrice())) .setScale(2, RoundingMode.HALF_UP); remaining remaining.subtract(usedInTier); } return totalFee; } }这个算法的思路是把每个阶梯想象成一个“容量有限的水桶”用户用量先填第一档填满了再流进第二档以此类推。用remaining记录还没有被计费的用量每进入一个阶梯就消耗一部分。边界情况是最后一档tierEnd为null表示上不封顶直接把remaining乘以单价即可。为什么用BigDecimal而不是double因为double在计算小数时会丢失精度0.1 0.2都会出现误差。金额计算类的场景必须用BigDecimal这是Java开发的铁律。在代码中我还用了RoundingMode.HALF_UP也就是四舍五入避免金额出现超长小数。水费计算逻辑和电费完全一致只是rule.getType()不同。把费用计算抽成独立服务后后面在做批量生成账单时只需要循环房间列表一个个调用计费服务就行代码非常干净。6. 核心功能实现三缴费与账单管理6.1 月度账单的生成策略账单不能实时生成而是采用“月度批量生成”策略。月末抄表完成后管理员点击“生成当月账单”按钮后端遍历所有有抄表记录的房间计算费用生成账单记录。这里要考虑一个重复生成问题。如果管理员误操作点了两次“生成账单”同一月份同一房间就会生成两条账单。我的解决方案是在meter_record表上加一个status字段抄表录入后status为0生成账单后置为1。生成账单的接口只处理status0的抄表记录处理完立即更新状态。同时在bill表上加唯一索引(room_id, record_month)数据库层面兜底双保险确保不会重复。批量生成的伪代码如下Transactional public void generateMonthlyBills(String month) { // 1. 查询所有未生成账单的抄表记录 ListMeterRecord records meterRecordMapper.getUnbilledRecords(month); for (MeterRecord record : records) { // 2. 计算水电费用 BigDecimal waterFee feeCalculateService.calWaterFee(record.getWaterUsage(), month); BigDecimal electricFee feeCalculateService.calElectricFee(record.getElectricUsage(), month); // 3. 创建账单 Bill bill new Bill(); bill.setRoomId(record.getRoomId()); bill.setRecordMonth(month); bill.setWaterFee(waterFee); bill.setElectricFee(electricFee); bill.setTotalFee(waterFee.add(electricFee)); bill.setStatus(0); billMapper.insert(bill); // 4. 更新抄表记录状态 record.setStatus(1); meterRecordMapper.updateById(record); } }看到Transactional注解了吗这个方法必须在事务中执行否则中途某个房间计算失败前面的房间已经生成了账单后面的房间却还是待生成状态数据就不一致了。加了事务之后任何一个房间失败整批操作全部回滚。这是生产环境级别的严谨性论文里写出来也是加分项。6.2 缴费流程与数据状态流转在线缴费流程要区分“模拟支付”和“真实支付”。毕业设计通常没有对接支付宝或微信支付的资质所以源码里通常用的是模拟支付学生点击“去缴费”系统生成一笔缴费记录状态置为已支付更新账单状态。如果要做得更有说服力可以在缴费页面展示一个“二维码”图片可以随便放然后提供一个“模拟支付成功”的按钮等于是演示了完整流程。缴费成功后账单状态从0未缴费变为1已缴费同时写入payment_record表。用户查询账单列表时能清晰看到每个月的费用明细和交费状态。这里要关注一个细节账单和缴费记录建立关联之后不能允许同一张账单重复缴费。我给bill表加了status判断只有status0的账单才能发起缴费支付成功后先更新账单状态再插入缴费记录两步操作放在同一个事务里。这样即使并发请求打过来也最多只有一笔操作能成功。统计报表方面按楼栋汇总月用电量、按学院汇总欠费金额、按学期对比用水量这些SQL都相对简单但输出格式要做统一封装。我通常会定义一个DashboardVO把总房间数、已入住数、本月用水总量、本月用电总量、本月应收总费用、已缴费用、欠费金额这些聚合数据一次性返回给前端。前端就能直接渲染成一个数据看板视觉效果和专业度都拉满论文里的“系统测试”章节也用得上。7. 系统部署与论文写作的实战经验7.1 本地环境搭建与快速启动指南拿到源码后最快的启动步骤是“三步法”初始化数据库用Navicat或命令行执行sql目录下的init.sql脚本创建数据库和表结构。修改配置文件打开application.yml改数据库连接的用户名和密码。有些项目的数据库账号不是root或者MySQL端口不是3306这些都要改成自己的环境。启动项目用IDEA打开项目等待Maven下载完依赖找到主启动类右键Run。看到“Started ... in xxx seconds”的日志就说明启动成功了。这里有个高频问题Maven依赖下载不下来或者下载速度极慢。解决方案是修改Maven的settings.xml把镜像仓库换成阿里云的mirror。这不是教程里会写的东西但几乎所有新手实战时都会卡在这。换完镜像后依赖基本秒下。启动成功后先别急着登录系统用Postman或者浏览器直接访问一下接口文档地址确认后端是通的。如果项目集成了Swagger访问/swagger-ui/index.html就能看到所有接口和参数说明这个页面不仅方便调试写论文时截图也是很好的素材。7.2 论文撰写的逻辑主线与图表建议这篇论文的写作逻辑建议按“发现问题—分析问题—解决问题—验证结果”四段式展开。背景部分强调传统水电管理的痛点手工抄表效率低、数据不透明、费用计算容易出错、学生缴费不方便。技术选型部分重点解释为什么选Spring Boot而不是简单罗列技术名称——因为Spring Boot简化了项目搭建和配置内置Tomcat让部署变得容易生态丰富方便集成其他组件。系统设计章节建议画三张图一是系统总体架构图展示前端、后端、数据库的层次关系二是功能模块图用树状图展示系统的功能结构三是数据库ER图把六张核心表以及它们之间的关系画清楚。这三张图是论文的骨架有了它们内容就顺理成章。代码实现章节不必把源码全部贴上去选三个核心功能的代码即可登录鉴权的核心代码、费用计算的算法代码、批量生成账单的代码。每个代码块后配上两三段解释说明设计思路和实现细节。我发现不少论文的代码是纯堆砌没有任何解释这其实很吃亏——评委想看到的是你理解这段代码而不是复制粘贴。测试章节用表格展示测试用例比如正常缴费流程、重复账单生成、阶梯计费边界等表格说清楚输入、预期输出、实际输出和结论。8. 常见问题与避坑指南8.1 启动与运行阶段的经典故障这个项目跑起来的时候最常见的坑基本集中在几个地方数据库连接失败。报错一般是“Access denied for user”或者“Communications link failure”。前者是账号密码错了后者是MySQL没启动或者端口不对。遇到这种报错先ping一下数据库再用命令行登录试试逐层排查。有一点务必确认MySQL 8.x的驱动类名是com.mysql.cj.jdbc.Driver在pom.xml中引入mysql-connector-java时要注意版本兼容性推荐用8.0.33。项目端口被占用。默认端口8080如果本机装了其他服务占用了8080启动会直接报错。最简单的处理方式是改配置文件里的server.port为8081、9090等不常用的端口。这个坑在答辩现场特别常见我记得有个同学答辩前两小时发现端口被占用当时慌得不行。MyBatis Plus表名映射问题。数据库表名是sys_user实体类名是SysUserMyBatis Plus默认的驼峰转下划线规则可以正常映射。但如果你给实体类起名UserMyBatis Plus会在数据库中找user表如果你的表叫sys_user就会报表不存在的错误。解决方案是在实体类上加TableName(sys_user)注解一劳永逸。8.2 从能跑到能讲的细节优化源码能跑只是第一步答辩时能讲清楚才是关键。我建议拿到任何源码后做三件事第一把项目的数据库初始化脚本完整执行一遍然后自己手动插入几条测试数据熟悉表结构。尤其是用户表里的角色字段管理员账号和普通学生账号的数据要清楚哪个账号是管理员、哪个是学生面试官问起来要能脱口而出。第二跑通一遍完整业务流程管理员登录→录入抄表→生成账单→学生登录→查看账单→缴费→管理员查看统计报表。走完这个流程你就对系统有了全貌性的理解任何功能的代码在哪、数据存在哪张表、状态如何流转心里都有一张地图。第三主动改一两个小功能练手。比如把系统中的水费单价从固定值改成可配置的阶梯计费或者给账单列表加一个导出Excel功能。改代码的过程会迫使你真正理解原有代码的设计逻辑这是从“会跑”到“会讲”的关键一步。有些同学答辩时被问代码细节就卡壳就是因为只看过没改过说到深层就露馅了。8.3 功能扩展的四个方向如果这套系统做完还有富裕时间我建议挑一两个方向扩展。比较实用的扩展方向包括对接微信公众号或企业微信学生绑定房间后每月账单自动推送提醒欠费也能收到通知增加微信支付/支付宝支付的模拟沙箱对接把缴费流程做成真实的支付链路引入定时任务框架如Spring Task或Quartz每月1号自动生成本月账单减少管理员手动操作增加报修功能学生可以在线提交水管漏水、电灯损坏的工单物业后台接单处理形成“水电管理维修服务”的闭环我当时给一个学弟的建议是优先做定时任务因为成本最低、代码量小、演示效果直观。在Spring Boot主类上加EnableScheduling注解然后写一个Component修饰的定时任务方法用Scheduled(cron 0 0 0 1 * ?)每月1号零点触发批量生成账单逻辑。这段代码不到30行但答辩时能讲清楚定时任务的原理就是很大的亮点。从我个人的经验来看做这类管理系统的毕业设计真正的难点从来不是某个技术点有多难而是能不能把业务逻辑理清楚再把代码组织得有层次感。Spring Boot把框架层面的复杂度降低了很多剩下的核心就在于业务建模和细节处理上。多看几遍源码里实体类和数据表之间的对应关系多跑几遍完整流程多改几个功能试试这个项目就能真正变成你自己的东西。最后再分享一个小技巧去答辩前一定要在干净环境重新部署一次项目也就是把数据库删掉重新执行init.sql把IDEA的缓存清一下然后完整启动一遍。这么做的目的不是检查代码能不能跑而是让你记住整个部署过程里有哪些坑熟悉到闭着眼睛都能解决。答辩现场环境跟开发环境基本不一样谁能快速解决部署问题谁就掌握了主动。本文还有配套的精品资源点击获取