SpringBoot+JavaWeb实战：小区车辆管理系统毕设全流程解析

做毕业设计选“小区车辆管理系统”，听起来很平常，但真正从头到尾把它做扎实，其实涉及的东西一点都不少。同样是这个题目，有人交上去的是一个只能点点页面的Demo，有人却能交出一套业务逻辑闭环、数据库设计规范、答辩能讲明白的完整项目。这篇博客就以我实际开发这套基于SpringBoot和JavaWeb技术栈的小区车辆管理系统为例，把从选题、表结构设计、后端接口开发、前端页面实现，到文档撰写和答辩演示的全过程拆开来讲，包括每一环节里踩过的坑和最后的处理方法。系统本身的技术方案是SpringBoot + MyBatis + MySQL，前端采用Thymeleaf + Bootstrap，非常贴近主流毕设技术栈，适合正在做同类型项目或者想参考一套完整案例的同学。

1. 选题逻辑：为什么“小区车辆管理系统”是计算机毕设的稳妥牌

1.1 业务链条完整，复杂度刚好卡在“能做完”和“有内容”之间

毕设选题最怕两种：一种是太简单，比如单表增删改查，答辩时没什么可讲的；另一种是太复杂，比如要搞分布式微服务，做到最后自己都讲不清楚。小区车辆管理系统恰好卡在中间。

从业务端看，它不是一个孤立的表，而是一条条业务链路串起来的系统：业主先登记，然后车辆绑定业主，再分配车位，月租车定期缴费，临时车按规则计费，每次进出场都要形成记录，后台还有统计报表。整条链路覆盖了用户管理、车辆管理、车位管理、缴费管理、记录管理五个核心模块。每个模块单独拎出来都是标准的增删改查，但组合在一起就有业务逻辑了。

这种“单模块不难、整体有逻辑”的状态对毕设来说非常理想。它保证了哪怕你从零开始，一个月内也能做出来，同时又有足够的业务深度供你在文档和答辩时展开讲解。比如你可以解释车辆与业主的关系是一对多还是多对多，临时车和月租车的计费策略怎么设计，离场记录和历史缴费如何关联查询，这些都能成为答辩时的加分点。

1.2 技术选型：为什么从传统JavaWeb过渡到SpringBoot

很多学校课程还在教Servlet + JSP那套JavaWeb开发方式，但实际做毕设时，我更推荐直接用SpringBoot。不是否定JavaWeb，而是SpringBoot就是JavaWeb在现代工程里的标准做法。

传统JavaWeb项目需要手动配置web.xml、Spring容器、MyBatis整合、Tomcat发布，每一步配置都耗费大量时间，而且版本稍微不一致就报错。SpringBoot把这些东西全部内聚了，内置Tomcat，配置通过application.yml文件搞定，依赖用Maven统一管理，启动就是一个main方法。从毕业设计的周期出发，把配置时间压缩下来，把精力放到业务逻辑上，性价比高得多。

这里也提醒一句：SpringBoot版本不是越新越好。我见过很多同学一上来就选SpringBoot 3.x，结果JDK必须升到17，有些老的依赖还兼容不了，网上搜到的教程大多针对2.x，出了问题排查半天。如果是为了稳妥，建议选SpringBoot 2.7.x + JDK 1.8这套经典组合，资料多、兼容性好、跑通率最高。

1.3 避免同质化的三个切入点

“小区车辆管理系统”确实有不少人做，但同题不同质。想让自己的项目在答辩时有辨识度，可以从下面三个方向切入：

• 数据可视化：在首页加一个统计面板，展示总车辆数、当前在场车辆、今日临停车次、月租缴费率等指标，用ECharts图表呈现。这一项直接拉高项目观感。
• 缴费提醒与逾期处理：月租车到期前三天自动标记为“即将到期”，过期未缴费的车辆出场时按临时车计费。这个逻辑能体现你对业务的理解。
• 操作日志：记录谁在什么时间做了哪次关键操作，管理员可以在系统里查看操作留痕。大部分同学的系统都没有这一块，你加上了就是差异化。

要强调的是，这三个方向不需要全部实现，哪怕只做其中一个，都可以作为文档里的重点章节和答辩中的亮点来介绍。

2. 功能边界与数据库设计：先想清楚表的关系，再动手写代码

2.1 系统角色与核心业务链路

小区车辆管理系统的角色不需要设计得太复杂，通常就两类：

• 系统管理员：负责业主信息录入、车辆信息登记、车位分配、缴费记录确认、查看进出场记录、发布公告、系统设置。
• 业主/住户：通过登录查看自己的车辆信息、缴费记录、缴费状态，提交月租续费申请，查看公告。

有些系统会增加一个“保安/门岗”角色，用于操作进出场记录。如果不想把权限体系做太重，可以将这个功能合并到管理员角色中，做一个“车辆登记进出”的菜单入口即可。毕设系统千万不要把角色和权限做得和RBAC那样细，否则开发量会明显上升，性价比不高。

核心业务链路可以概括为：业主登记 -> 车辆绑定 -> 分配车位 -> 正常进出场 -> 离场计费 -> 生成缴费记录 -> 后台统计。所有模块围绕这条主线展开，不要随便加和这条链路无关的功能。

2.2 核心数据表的设计

数据库设计是整套系统的根基，也是答辩时老师必问的部分。我根据业务链路将核心表拆成了六张，关系清晰，也方便后续扩展：

以record表为例，它里面冗余了plate_no字段，而不仅仅存放car_id。原因是如果车辆信息被修改或者车辆被删除，历史进出场记录仍然需要保留当时的车牌号，否则报表就会出现空数据。这是实际开发中很常见的设计经验，也是答辩时能体现你思考深度的细节。

2.3 容易忽略的细节和索引问题

设计表结构时，有几个细节容易被忽略，这里单独说一下：

• 记录表的status字段建议直接使用TINYINT，0表示未离场，1表示已离场，不要用字符串去存状态，避免后续统计时还需要字符匹配转换。
• 金额字段使用DECIMAL(10,2)，不要用FLOAT或DOUBLE，否则后续计算费用会出现精度问题。
• 建议所有表都加上create_time和update_time字段，用途一是开发时排查数据方便，二是文档里可以写“系统设计了自动填充时间字段”，显得规范。
• 物理外键在毕设里建议少用，表与表之间的关系用逻辑外键维护即可。原因是在后期需要造测试数据或修改记录时，物理外键会带来大量麻烦，而逻辑外键在代码里控制完全够用。
• 索引方面，给car表的plate_no字段加唯一索引，给record表的in_time加普通索引，因为后续查询和统计基本都按这两个维度走。

3. SpringBoot工程的搭建与配置：环境选对，后面才不折腾

3.1 开发环境版本搭配

先列一套我实测下来最稳的组合，直接照着装就行：

这里特别提一下SpringBoot版本。网上有一种倾向是永远追最新版，但在毕设场景下这不是好选择。SpringBoot 2.7.x已经是2.x系列的稳定版本，资料全、各种问题的解决方案都能搜到，而且不存在“版本太高”带来的依赖不兼容问题。如果你一定要用3.x，我也拦不住，但请先确认你的JDK是17及以上，且所有第三方starter都有对应适配版本。

3.2 application.yml的核心配置

创建项目之后，第一件事是配置application.yml。这是我项目里用到的核心配置片段：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/community_car?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
    username: root
    password: 123456
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.communitycar.entity
  configuration:
    map-underscore-to-camel-case: true

有几个配置项是当年我踩过坑才加上的：

• serverTimezone=Asia/Shanghai：MySQL 8.0如果没有指定时区，连接时经常报错，加上这个基本能解决。
• useSSL=false：本地开发不需要SSL校验，加上可以避免无谓的手续。
• allowPublicKeyRetrieval=true：MySQL 8.0使用caching_sha2_password认证时，如果缺少这个参数会报Public Key Retrieval is not allowed。
• mybatis.configuration.map-underscore-to-camel-case：开启后数据库的plate_no字段能自动映射到Java实体类的plateNo属性，极大减少手写映射的体力活。

另外，代码里不要出现任何账号密码的硬编码写死在代码中的情况，虽然毕设不是上生产环境，但把数据库密码写在application.yml里是常规做法，这个不用改，只要别把代码提交到公开平台就行。

3.3 统一返回结果与全局异常处理

管理系统前后端交互时，接口返回的数据格式最好统一，这样前端解析起来省很多事。我这边定义了一个Result类，所有Controller的返回值统一用它包装：

java复制public class Result<T> {
    private Integer code;
    private String msg;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.code = 200;
        result.msg = "success";
        result.data = data;
        return result;
    }

    public static <T> Result<T> error(Integer code, String msg) {
        Result<T> result = new Result<>();
        result.code = code;
        result.msg = msg;
        return result;
    }
}

同时配一个全局异常处理器，用@RestControllerAdvice统一拦截业务异常，这样Controller里就不需要每个方法都写try-catch，代码干净很多，服务端也不会把500错误直接抛给前端。

3.4 启动失败的常见排查

项目一旦启动失败，先别急着找代码问题，按照这个顺序排查往往更快：

1. 端口是否被占用，改server.port或者结束占用进程。
2. MySQL服务是否启动，用Navicat或命令行test一下连接。
3. Maven依赖是否完整，多执行几次clean + install。
4. 控制台具体报错信息，定位到某一行，再搜索解决方案。SpringBoot的报错信息和网上答案基本是逐字对应的。

4. 核心功能实现：从登录到计费的一整条业务链路

4.1 登录鉴权：JWT还是Session

登录功能是每个毕设系统的门面，也是答辩时老师比较关注的点。对于这种非高并发系统，JWT和Session两种方案都可以，但如果想体现技术深度，我建议用JWT。

JWT的核心原理是用户登录成功后，服务端生成一个带签名信息的Token返回给前端，前端每次请求时把它放到请求头里，服务端通过拦截器校验Token的合法性，从而识别用户身份。优点是服务端不需要保存会话状态，天然适合前后端分离。

实现时通常包含三部分：生成Token的工具类、校验Token的拦截器、放行白名单。白名单里有登录接口、静态资源、错误页面，其余接口全部拦截校验。这里容易踩坑的是静态资源被拦截器挡住，比如CSS、JS、图片全部加载不出来，后面我会在踩坑章节单独讲。

用Session方案也可以，SpringBoot里通过HttpSession存取用户信息，更加简单，但答辩时讲不出太多东西。建议如果不是特别缺时间，就做JWT，并把它的无状态特性讲清楚，这会是一个技术亮点。

4.2 车辆管理模块的增删改查实现

车辆管理是整个系统的核心模块。这里以车辆信息查询接口为例，展示经典的三层结构写法。先看接口定义：

java复制@RestController
@RequestMapping("/api/car")
public class CarController {

    @Autowired
    private CarService carService;

    @GetMapping("/list")
    public Result<PageResult<Car>> list(@RequestParam(defaultValue = "1") Integer pageNum,
                                        @RequestParam(defaultValue = "10") Integer pageSize,
                                        @RequestParam(required = false) String plateNo) {
        return Result.success(carService.queryPage(pageNum, pageSize, plateNo));
    }

    @PostMapping("/add")
    public Result<Void> add(@RequestBody Car car) {
        carService.addCar(car);
        return Result.success(null);
    }

    @PutMapping("/update")
    public Result<Void> update(@RequestBody Car car) {
        carService.updateCar(car);
        return Result.success(null);
    }

    @DeleteMapping("/delete/{id}")
    public Result<Void> delete(@PathVariable Integer id) {
        carService.deleteCar(id);
        return Result.success(null);
    }
}

Service层的职责是业务处理，比如添加车辆时检查车牌号是否重复、车辆状态是否正常；删除车辆时检查该车是否有未完成的进场记录，如果有则提示先处理离场记录，避免数据不一致。

Mapper层则是MyBatis的接口，配合XML里的SQL执行数据库操作。这里使用PageHelper做分页插件，一句话就能搞定分页查询，比自己拼LIMIT参数方便得多。

这套Controller-Service-Mapper结构几乎是所有毕设项目的标准写法，不一定要用到多高深的设计模式，但子一定要分清楚层次，这也是文档里重点要写清楚的部分。

4.3 停车费计算逻辑

停车费计算是整个系统里最典型的一段业务逻辑，答辩时几乎必问，所以这块一定要想清楚。

我的计费规则分两类：

• 月租车：按月/季/年缴费，缴费成功后关联的车辆在有效期内出场不再按次计费。到期未续费的车辆，出场时转为临时车计费标准。
• 临时车：入场后记录进场时间，出场时按停车时长计算费用。规则为：首小时5元，之后每小时2元，24小时内封顶20元，超过24小时重新累计。

实际代码中，这个逻辑放在Service层方法里，核心思路如下：

java复制public BigDecimal calculateFee(Record record) {
    long minutes = Duration.between(record.getInTime(), record.getOutTime()).toMinutes();
    if (minutes <= 0) {
        minutes = 30; // 最低按半小时计
    }
    int hours = (int) Math.ceil(minutes / 60.0);
    if (hours <= 1) {
        return new BigDecimal("5.00");
    }
    BigDecimal fee = new BigDecimal("5.00")
            .add(new BigDecimal(hours - 1).multiply(new BigDecimal("2.00")));
    // 封顶
    if (fee.compareTo(new BigDecimal("20.00")) > 0) {
        return new BigDecimal("20.00");
    }
    return fee;
}

这段逻辑里最需要注意的是边界条件：不足一小时按一小时算、封顶逻辑、超过24小时的重新累计。这几个边界点正是答辩时老师喜欢追问的地方，你如果能在文档里把这个过程写清楚，会显得思路非常严谨。

4.4 进出场登记与状态流转

进出场功能涉及多张表的联动操作，必须有事务控制。

进场时：

1. 根据车牌号查车辆信息，如果车辆不存在则提示“请先登记车辆”。
2. 检查车辆当前是否有未离场记录，如果有说明车还在地下停车场，不允许再次进场。
3. 检查车位空闲状态，找到一个空闲车位绑定到本次记录。
4. 在record表插入一条进场记录，status为0，in_time为当前时间。

出场时：

1. 根据车牌号查出当前未离场的记录。
2. 更新out_time为当前时间。
3. 如果是临时车，调用计费方法计算费用；如果是月租车且在有效期内，费用为0。
4. 更新record表的status为1，释放绑定的车位为空闲。
5. 插入一条payment缴费记录。

整个流程必须在同一个方法中完成，并加上@Transactional注解，任何一个环节报错，前面的数据变更都要回滚。这里有一个很经典的坑是事务自调用失效，后面踩坑章节我会细讲。

5. 前端实现：界面不用多华丽，但结构一定要完整

5.1 方案选择：Thymeleaf + Bootstrap还是Vue前后端分离

前端方案在毕设里困扰很多人。我的观点是：如果你对Vue不熟，真的别硬上前后端分离，老老实实用Thymeleaf + Bootstrap，一天就能把页面框架搭起来。

Thymeleaf是SpringBoot官方推荐的模板引擎，可以在HTML页面里直接写服务端渲染的语法，比如从Model中取值、遍历列表、条件判断。配合Bootstrap或AdminLTE这类现成的后台管理模板，页面效果完全够用，而且省去了跨域、Token、打包部署这些和毕设业务无关的麻烦。

如果你确实熟悉Vue，可以采用SpringBoot + Vue前后端分离的方案，把后端返回JSON数据、前端通过Axios请求调用，整体结构更现代。但代价是前端工程要单独创建、单独打包，部署时还要处理跨域问题，开发周期至少多出一周。如果时间充裕且想锻炼一下，可以考虑；如果求稳，就选服务端渲染方案。

5.2 页面布局与常用模板

后台管理系统的页面结构基本是固定的：顶部导航栏、左侧菜单、右侧内容区。建议直接用AdminLTE或SB Admin模板改造，不要自己从零写CSS框架的布局，省时省力效果还好。

我当时的做法是：

• 下载一份AdminLTE的HTML模板。
• 把公共的头部和侧边栏抽成Thymeleaf的fragment片段，其他页面通过th:replace引用。
• 页面中的表格数据通过Thymeleaf的th:each渲染，而不是用Ajax拼HTML。

这样做的最大好处是页面的结构清晰，每一页都是后端返回数据后直接渲染出来的，开发和调试都非常直观。比如车辆列表页，Controller返回一个包含车辆列表的Model，页面写一个表格循环输出即可。

5.3 前端与后端接口的交互方式

在不做前后端分离的情况下，前端和后端的交互有两种常见方式：

• 表单提交：新增、编辑类操作，用form表单POST到Controller，Controller执行完业务后重定向回列表页或直接返回JSON提示。
• Ajax异步刷新：列表的删除、状态修改，以及部分弹窗操作，用jQuery的$.ajax或$.post请求后端接口，前端收到响应后刷新页面。

这两种方式结合起来，基本能覆盖所有管理系统的交互场景。要注意的是，如果用Thymeleaf渲染列表，删除或修改后要返回重定向地址，前端拿到后跳转，才能保证页面数据实时刷新；如果用Ajax，则可以在success回调里再调用一次查询接口刷新表格，或者直接reload当前页面。

这里的核心原则是保持一致：同一个功能模块的交互方式不要一会儿表单提交一会儿Ajax，否则代码会越来越乱，自己都难维护。

6. 开发中踩过的坑：这些问题不排查一下午真过不去

6.1 MyBatis的mapper.xml不生效

这是新手最常见的坑。辛辛苦苦写好了Mapper接口和XML文件，启动时报Invalid bound statement (not found)，或者直接找不到SQL语句。

这个坑的常见原因有以下几个：

• 没有在application.yml中配置mybatis.mapper-locations，或者路径写错，导致XML文件没有被加载。
• XML文件的namespace没有写全，或者namespace中的接口路径与Mapper接口不一致。
• Mapper接口方法名与XML中select/update标签的id不一致。
• XML文件没有被Maven打包到target目录。解决方法是检查pom.xml的resources配置，确保src/main/resources下的xml文件被包含。

排查思路很简单：先看target目录下有没有对应的XML文件，没有就检查Maven配置；有的话就检查namespace和id。

6.2 日期格式与JSON序列化问题

另一个高频问题是时间字段返回给前端时变成了时间戳数字，或者格式不是预期的yyyy-MM-dd HH:mm:ss。

原因在于后端返回的LocalDateTime或Date类型，默认通过Jackson序列化时没有指定格式。解决方法是统一在application.yml中配置：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

或者在日期字段上用@JsonFormat注解单独指定格式。建议优先用全局配置，再对特殊字段单独注解。

另外一个相关坑是前端接收到的日期和实际时间差了8小时，这是时区问题。配置中加上time-zone: GMT+8即可解决。

6.3 MySQL连接失败与驱动版本问题

初学阶段连接数据库报错，十有八九是驱动类写错了。MySQL 5.7及以前版本的驱动类是com.mysql.jdbc.Driver，而MySQL 8.0以后改成了com.mysql.cj.jdbc.Driver。

如果你的本地MySQL是8.0，还是用旧驱动，启动时大概率会报ClassNotFoundException或连接失败。解决方法是统一使用com.mysql.cj.jdbc.Driver，并且在pom.xml里引入版本与MySQL服务端匹配的mysql-connector-java依赖。

6.4 静态资源被拦截器拦截

做完JWT拦截器之后，打开登录页面发现CSS样式全丢了，页面丑得没法看，这种问题几乎人人都会遇到。

原因很简单：拦截器拦截了所有请求，导致/cs/**.css、/js/*.js这些静态资源被拦截，没有放行。解决方式是在拦截器配置类中添加静态资源的放行路径：

java复制registry.addInterceptor(jwtInterceptor)
        .addPathPatterns("/**")
        .excludePathPatterns("/login", "/api/login", "/css/**", "/js/**", "/images/**", "/error");

这里还要注意，如果使用了Thymeleaf，模板页面本身不受拦截器影响，但页面引用的静态文件路径要确认能正常访问。

6.5 SpringBoot事务自调用失效

最后说一个比较隐蔽的坑。在同一个类中，一个方法调用另一个带有@Transactional注解的方法，事务会失效。因为Spring的事务是基于AOP代理实现的，同类调用不会经过代理对象，注解自然不生效。

我遇到过的情况是：在进场方法中调用了同类的checkAndUpdateSpace()方法，这个方法本身有@Transactional注解，但实际执行时事务完全没有开启。数据库更新一半报错后，数据还是改了。

解决方式的思路有两种：

• 把需要事务控制的内部方法拆分到另一个Service类中，由Spring注入后调用，让事务通过代理生效。
• 将事务边界上移到入口方法上，整个业务方法一个注解搞定。

无论选哪种，核心原则是事务一定要加在“从外部进入Service的入口方法”上，也就是Controller直接调用的那层方法。

7. 文档、答辩与扩展方向：把项目从“能跑”变成“能打”

7.1 毕业设计说明书的结构

文档是毕业设计评审的重头戏，很多同学代码做得还行，但文档写得一塌糊涂。一份合格的小区车辆管理系统说明书，结构一般是这样的：

1. 绪论：项目背景、国内外研究现状、项目目标。
2. 需求分析：功能性需求、非功能性需求、可行性分析。
3. 系统设计：总体架构、功能模块划分、业务流程分析。
4. 数据库设计：ER图、数据表结构说明。
5. 系统实现：每个模块的界面截图和核心代码说明。
6. 系统测试：测试用例、测试结果、缺陷分析。
7. 总结与展望：项目亮点、不足、后续改进方向。

写文档时最容易犯的错误是把大段源码直接粘贴进去。老师要看的不是代码本身，而是你对设计的思考。可以用“本模块实现了XX功能，通过XX方法解决XX问题，关键流程为……”的方式描述，再配合少量关键代码片段即可。

7.2 答辩讲解的节奏与演示脚本

答辩时间一般是五到十分钟，别把时间耗在讲背景上，一定要把时间花在技术细节和亮点上。我的建议是：

• 第一分钟：一句话介绍项目背景和目标，说明系统采用SpringBoot + MyBatis + MySQL实现。
• 第二分钟：结合系统功能架构图，讲清楚系统有哪些角色、哪些核心功能模块。
• 第三到五分钟：打开系统现场演示，演示时按业务流程来，不要挨个菜单点。按“登录 -> 新增业主 -> 添加车辆 -> 绑定车位 -> 登记进场 -> 登记离场并计费 -> 查看缴费用记录”这条主线走一遍。
• 最后一两分钟：讲一两个技术亮点，比如JWT无状态认证、计费逻辑的边界处理、全局异常处理，并准备回答老师可能针对这些点的追问。

老师高频会问的问题，可以先自己准备一下：为什么选SpringBoot？表之间的关联关系是怎样的？临时车和月租车怎么区分？费用是怎么计算的？系统怎么保证并发情况下同一辆车不会同时进两次场？停车记录数据量大了怎么办？前三个问题如果回答流畅，答辩基本就稳了。

7.3 可落地的扩展方向

如果时间还有富余，可以在核心功能之外挑一两个方向做扩展，不必所有都做：

• 车辆信息和缴费记录导入导出：用EasyExcel做Excel的导入导出，这是实际开发中非常常见的需求，也能体现工程化能力。
• 定时任务提醒：用SpringBoot自带的@Scheduled注解，每天扫描即将到期的月租车，生成提醒列表。
• 移动端适配：做一个简单的H5页面，让业主可以在手机上查看车辆状态和缴费记录，不需要单独做App。
• 车牌识别接口对接：在当前系统中预留接口，模拟调用第三方车牌识别服务，根据识别到的车牌号自动登记进场。如果条件不满足，可以做一个模拟识别页面来演示。

7.4 定制扩展时如何不动摇原有基础

最后聊一下“定制”的问题。很多人拿到别人的毕设项目之后，想自己加功能，但一改就崩。其实核心在于改之前先搞清楚原有的数据流向。

以我为例，我后期给系统加了一个“公告管理”功能，操作很简单：新增notice表，创建实体和Mapper，在后台菜单加一个入口，写一套增删改查，然后在前台首页展示公告列表。关键是这个模块和原有车辆业务流程没有任何关联，所以几乎不会影响系统稳定性，风险极低。

如果扩展的功能要改动原有表结构，比如要在record表里加一个“入场通道”字段，操作时就小心一些：先备份数据库，加字段后同步修改实体类和Mapper的查询列，再跑一遍完整的进出场流程测试，确认没有报错才能算完成。扩展永远是增量修改优先，尽量不要去重构原有代码逻辑，尤其是已经跑通的计费逻辑。

最后再分享一点个人体会：花在需求分析和表结构设计上的时间，最终都会在开发阶段一百倍地还回来。我一开始也想着赶紧写代码，结果表结构设计得不够稳，后面反复改表、改Mapper、改页面，反而浪费了更多时间。后来重新把业务流程和表关系梳理清楚，再动手就顺利很多。如果你现在也在做这个选题或者正在纠结毕设怎么做，先把业务链路和数据库设计画清楚再动手，这个顺序一定不会错。做出来的系统不需要多酷炫，只要逻辑闭环、能讲清楚，就是一份合格的毕业设计。