SpringBoot+Redis停车场管理系统：并发预约与计费策略实战

1. 项目概述

1.1 为什么停车场管理系统是毕设选题的“稳妥之选”

每年毕业季，Java方向的学生翻来覆去选的就那么几个方向：图书管理、超市收银、教务系统、停车场管理。停车场管理系统能成为常青树题目，不是因为简单，而是因为它的业务闭环非常完整——从用户注册到车位预约、入场识别、出场计费、支付结算，再到管理端的车位调度、订单统计，整条链路全是“刚需场景”。真正把这一套逻辑跑通并解释清楚，已经足够体现一个毕业生的工程能力了。

我看到不少学生对这个题目的理解停留在“增删改查”层面：车位表、订单表、用户表，然后套一个SpringBoot脚手架，写几个Controller就交差。这样做的结果就是答辩时老师问一句“如果两个人同时预约同一个车位怎么办”，当场尬住。所以这个题目真正拉开差距的地方，不在于你用了多少张表，而在于三个核心问题：并发控制怎么做、计费规则怎么设计、车位状态怎么流转。

这篇博文我会从一个完整的毕设项目视角出发，把系统设计、库表结构、关键代码、问题排查全流程过一遍，重点讲那些“网上八股文里看不到”的实操细节。不管你是第一次做这种项目的新手，还是已经在写了但卡在某一步想找人聊聊的老手，都能在这篇文章里找到对应答案。

1.2 项目核心需求拆解

先把这个系统需要承载的核心需求列出来，这也是答辩时老师最关心的事情。

从用户端来看，一个停车场管理系统至少要有四块功能：账号注册登录、车位实时查询与预约、个人订单管理、在线缴费。注意“预约”和“缴费”是业务上的两个关键节点，很多学生把缴费做成了跳过预约直接生成订单，逻辑上不够严瑾，答辩容易翻车。

从管理端来看，需要包括：车位信息管理（新增、禁用、删除）、车辆入场出场记录、订单金额结算与异常订单处理、基础收入统计。其中入场出场记录非常关键，它和预约订单之间存在关联关系，处理不好会出现数据对不上账的问题。

如果你要往“还可以做得更好”的方向走，可以补充两块：一块是月卡用户计费规则，另一块是车位占用热力图或者高峰期统计。这两块在论文里能作为“创新点”写进去，也能在演示的时候多几个拿得出手的页面。

2. 技术选型与整体设计

2.1 技术栈选择的逻辑：不止是“流行”，而是“为什么”

SpringBoot + MyBatis Plus + MySQL + Redis这套组合，几乎成了Java后端毕设的标准答案。但如果你只是“大家都在用所以我也用”，答辩时老师问一句“为什么用MyBatis Plus而不是MyBatis”可能就答不上来。

说句实话，选MyBatis Plus的理由很实际：单表CRUD写的代码量少太多了。停车场管理系统的核心表就那么几张，项目里可能有七成以上的数据库操作是单表查询和简单更新，MyBatis Plus的BaseMapper直接带走了这些工作量。省下来的时间可以用在真正的业务逻辑上，比如预约并发控制和计费规则。而MyBatis原生写法更适合复杂动态SQL场景，在这个项目里用不上太多。

Redis在这个项目里不是摆设，它的作用是解决“超卖”问题——两个用户同时预约同一个车位。这个问题我在后文会给出完整的代码方案。如果你的毕设不引入Redis，只靠数据库层面做控制，也能实现，但对并发场景的抗压能力不够，答辩时很容易被追问。

MySQL就不说了，8.0版本就行。我这里提醒一点，建表时字符集统一用utf8mb4，因为车位编号可能带中文字符，而且utf8mb4兼容表情符号，避免存入特殊字符时报错。

2.2 功能模块怎么拆：用户端与管理端的边界

项目框架搭建起来后，第一件事就是把模块边界画清楚。大多数毕设的项目结构是写成三个模块：controller、service、mapper。这只是一种代码分层，功能模块上我建议按下面的方式划分：

code复制parking-common          // 通用工具类、统一返回结果、异常处理
parking-user-api        // 用户端接口：登录、查询、预约、支付
parking-admin-api       // 管理端接口：车位管理、订单管理、统计
parking-core            // 核心业务：计费策略、预约锁、入场出场逻辑

这种模块拆分不是为了写论文凑字，而是实际开发中确实能减少代码混乱。比如计费规则放在core模块里，用户端和管理端共用，避免出现“管理端算出来的费用和用户端页面显示的不一致”这种尴尬问题。

如果你是用单工程写，问题也不大，但至少包名要按这个思路分好。很多学生一个项目几千行代码全堆在com.example.demo下面，答辩时项目经理出身的老师一眼就能看出来代码组织有问题。

2.3 一个容易被忽略的设计提醒：系统是给谁用的

在设计之前，先想明白一个问题：这个系统到底是给“普通车主”用，还是给“管理员”用？答案当然是两拨人都有。但很多学生做的时候不自觉把重心全放到了管理端，用户端的交互体验一塌糊涂。

这里我想提醒一个关键点：用户端的核心价值是“快速找到车位并完成预约”，所以首页一定要直观展示车位占用状态。至于管理端，核心价值是“看清每一笔订单的钱怎么来的”，所以列表页必须展示费用计算明细，比如入场时间、出场时间、时长、单价、最终金额。

想清楚系统是给谁用的，做出来的东西才会有产品思维。这个在答辩评分中非常加分，因为大多数毕设作品看起来就是个后台管理系统，而你的作品有完整的用户视角。

3. 数据库设计与核心业务逻辑

3.1 核心表结构设计：三张表足够撑起业务闭环

停车场管理系统的数据库表不需要很多，核心就是三张：用户表、车位表、订单表。我把自己实际用过的建表SQL核心字段写出来，你用的时候可以在此基础上加字段。

用户表的核心字段：

code复制id, username, password, phone, plate_number, 
create_time, update_time, status(正常/禁用)

这里有个小坑：password字段要存加密后的密文，不要明文存，用MD5加盐或者BCrypt都行。毕设答辩时老师常问“密码怎么存储”，你要是答明文被推翻的风险很大，而且这是安全领域的基础常识。

车位表的核心字段：

code复制id, space_no, location(区域), floor(楼层), type(普通/新能源/无障碍),
status(空闲/占用/预约/维修), fee_rate(每小时费用)

注意status字段是整个系统的核心状态，后文我会专门讲状态流转，这里是第一个关键点：车位状态必须是单一数据源，订单的状态不能反推车位状态，因为存在无预约直接入场的情况。

订单表的核心字段：

code复制id, order_no, user_id, space_id, plate_number,
type(临时/预约/月卡), status(待支付/已支付/已取消/已完成),
enter_time, exit_time, total_minutes, total_amount, pay_time

这张表是计费的数据基础。强烈建议订单编号order_no做成唯一索引，除了业务需要，还有一层用途是作为并发控制兜底，后面讲预约锁的时候会提到。

3.2 计费规则怎么设计：策略模式是标准答案

计费规则是整个系统里最有“设计感”的地方。我不建议把计费逻辑写死在业务代码里，那样以后改规则会痛不欲生。用策略模式把不同计费方式拆开，是答辩时能讲出东西的亮点。

计费策略接口：

java复制public interface BillingStrategy {
    // 计算订单金额，入参是停车时长（分钟）和基础费率
    BigDecimal calculate(long minutes, BigDecimal feeRate);
}

普通临时车策略实现：

java复制@Component("temporaryBilling")
public class TemporaryBillingStrategy implements BillingStrategy {
    // 首小时10元，超过部分每小时5元，不足一小时按一小时算
    @Override
    public BigDecimal calculate(long minutes, BigDecimal feeRate) {
        if (minutes <= 0) {
            return BigDecimal.ZERO;
        }
        long hours = (minutes + 59) / 60;
        if (hours <= 1) {
            return feeRate;
        }
        BigDecimal extraHours = BigDecimal.valueOf(hours - 1);
        return feeRate.add(extraHours.multiply(BigDecimal.valueOf(5)));
    }
}

注意这里有个细节：不足一小时按一小时算。这种“向上取整”的逻辑很多学生第一次会写错，写出直接拿分钟数乘以单价的结果，导致停车58分钟算出来的费用和停车1分钟一摸一样，或者费用对不上。

使用策略时，通过一个工厂类根据订单类型获取对应的Bean：

java复制@Component
public class BillingStrategyFactory {
    @Resource
    private Map<String, BillingStrategy> strategyMap;

    public BillingStrategy getStrategy(String type) {
        BillingStrategy strategy = strategyMap.get(type);
        if (strategy == null) {
            throw new BusinessException("不支持的计费类型");
        }
        return strategy;
    }
}

Spring会自动把容器里所有BillingStrategy实现类注入到Map里，key是Bean名称，这种写法在答辩时讲出来，能体现出你对Spring容器机制的理解，比单纯说“我用到了策略模式”有说服力得多。

3.3 车位状态流转：写死后端逻辑防呆

车位状态是这个系统的核心状态机，必须仔细设计。我见过太多人把状态设计成“0/1”，只有空闲和占用两种，结果预约这个功能一出来就不知道怎么处理了。

我使用的状态集合是四种：空闲、预约、占用、维修。

状态流转规则：

code复制空闲 + 用户预约 = 预约
预约 + 用户取消/超时未入场 = 空闲
预约 + 车辆入场 = 占用
空闲 + 车辆直接入场 = 占用
占用 + 车辆出场 = 空闲
空闲/占用 + 管理员操作 = 维修
维修 + 管理员操作 = 空闲

这段规则看起来简单，但很容易在实现的时候遗漏。最常见的问题是“预约超时未入场没有定时任务扫描”，导致预约状态永远卡死。一个简单的解决方案是启动一个定时任务，每5分钟扫描一次订单表，把预约时间超过30分钟且未入场的订单置为取消，同时把车位状态改回空闲。

java复制@Component
public class AppointmentTimeoutTask {
    @Resource
    private OrderMapper orderMapper;
    @Resource
    private SpaceMapper spaceMapper;

    @Scheduled(fixedDelay = 300000)
    public void handleTimeout() {
        LocalDateTime deadline = LocalDateTime.now().minusMinutes(30);
        List<Order> timeoutOrders = orderMapper.findTimeoutAppointments(deadline);
        for (Order order : timeoutOrders) {
            // 事务内更新订单状态和车位状态
            orderMapper.updateStatus(order.getId(), OrderStatus.CANCELLED);
            spaceMapper.updateStatus(order.getSpaceId(), SpaceStatus.FREE);
        }
    }
}

这是一种兜底方案，展示给老师看能反应出你对异常场景的考虑。如果在生产环境里做，可以用延迟消息队列实现更精准的方案，但毕设阶段定时任务完全够用，也更好解释。

4. 核心功能实操：从预约到缴清全流程

4.1 车位预约的并发控制：Redis分布式锁+唯一索引兜底

这个环节是整个项目的灵魂，也是大多数人没法在网上找到满意答案的地方。直接上代码，然后一步步解释为什么这样写。

预约接口的核心逻辑：

java复制@Transactional(rollbackFor = Exception.class)
public OrderResult reserveSpace(Long userId, Long spaceId) {
    // 1. 对某个停车位加上分布式锁，防止并发预约同一个车位
    String lockKey = "parking:space:lock:" + spaceId;
    boolean locked = redisTemplate.opsForValue()
        .setIfAbsent(lockKey, "1", Duration.ofSeconds(10));
    if (!locked) {
        throw new BusinessException("当前车位正在被操作，请稍后重试");
    }
    try {
        // 2. 再次检查车位状态，防止脏读
        Space space = spaceMapper.selectById(spaceId);
        if (!SpaceStatus.FREE.equals(space.getStatus())) {
            throw new BusinessException("车位已被预约或占用");
        }
        // 3. 创建订单
        Order order = buildOrder(userId, spaceId);
        orderMapper.insert(order);
        // 4. 更新车位状态为已预约
        spaceMapper.updateStatus(spaceId, SpaceStatus.RESERVED);
        return OrderResult.success(order);
    } finally {
        redisTemplate.delete(lockKey);
    }
    // 注意：这里代码依赖数据库唯一索引作为最后兜底，防止极端情况下的并发插入
}

为什么用Redis锁而不是直接用数据库事务？因为两个用户同时请求预约同一个车位时，事务内的查询不一定能防止并发。MySQL默认隔离级别是可重复读，两个事务可能同时读到车位状态为“空闲”，然后都执行update，最终数据出现脏状态。分布式锁把同一个车位的操作串行化，从源头消灭了并发冲突。

Redis锁有一个潜在风险：如果持锁的服务宕机，锁没有释放，会导致这个车位永久锁定。所以锁一定要设置过期时间，代码里设的是10秒，这个时间足够完成数据库操作。如果你在测试时发现预约操作经常报“操作太频繁”，可以适当放宽到15秒，但不要设得太长，否则出问题时等待时间会很难受。

最后一层保险是数据库的唯一索引。在订单表里建一个组合唯一索引（user_id, space_id, order_status），保证同一用户同一车位同时只能有一个进行中的订单。即使Redis锁被极端情况穿透，数据库也会拦住重复订单。

4.2 入场与出场流程：状态和时间戳是命根子

入场流程：车主在门口扫码或输入订单号，系统校验订单状态，如果是“预约”状态且车位在“预约”状态，就放行入场，同时把订单状态更新为“使用中”，车位状态更新为“占用”，入场时间写入订单表。

这里有一个业务细节：如果用户有预约但实际入场的时候系统显示“该车位已被占用”，有可能是管理员手动把车位改成了维修状态，或者上个用户出场时状态没回滚。为了防止这种情况，入场接口里要把状态流转先做幂等判断：

java复制if (!OrderStatus.RESERVED.equals(order.getStatus()) 
    && !OrderStatus.PAID.equals(order.getStatus())) {
    throw new BusinessException("订单状态不允许入场");
}

出场流程是计费的核心。出场时先记录出场时间，然后调用计费策略计算金额，生成订单费用，更新车位状态为空闲。注意出场操作必须在事务里完成，而且要先调用计费策略，再更新车位状态。顺序反了会导致数据库异常时出现“车走了但车位还占着”的情况。

4.3 模拟支付与回调机制：别把支付做成“跳过去”

毕设项目的支付功能有两个选择：对接真实支付网关，或者使用模拟支付。真实对接微信支付/支付宝需要商户号资质，学生基本拿不到，所以99%的情况是模拟支付。

模拟支付的实现思路很简单：用户点击“去支付”按钮，后端生成一个支付单，然后模拟支付回调接口被调用，将订单状态从“待支付”改为“已支付”。这个模拟回调设计得好不好，是答辩时能拉开差距的地方。

我的建议是写一个PayService接口：

java复制public interface PayService {
    PayResult pay(Long orderId, BigDecimal amount);
}

再写一个MockPayServiceImpl做模拟实现，里面sleep几秒钟模拟网络请求过程，然后返回支付成功结果。这样设计的好处是：以后如果想接入真实支付网关，只需要新增一个实现类，不需要改业务代码。讲清楚这一点，老师会认为你具备“面向扩展开发”的意识。

4.4 管理端订单查询与统计：多条件组合查询

管理端最核心的页面是订单列表。因为订单数据量可能会很大（模拟数据几千条没问题），要支持按订单号、车牌号、手机号、订单状态、时间范围组合筛选。

MyBatis Plus的分页查询配合LambdaQueryWrapper很容易实现：

java复制public PageResult<OrderVO> pageQuery(OrderQuery query) {
    LambdaQueryWrapper<OrderDO> wrapper = new LambdaQueryWrapper<>();
    wrapper.like(StringUtils.hasText(query.getOrderNo()), 
        OrderDO::getOrderNo, query.getOrderNo());
    wrapper.like(StringUtils.hasText(query.getPlateNumber()), 
        OrderDO::getPlateNumber, query.getPlateNumber());
    wrapper.eq(query.getStatus() != null, 
        OrderDO::getStatus, query.getStatus());
    wrapper.between(query.getStartTime() != null && query.getEndTime() != null,
        OrderDO::getEnterTime, query.getStartTime(), query.getEndTime());
    wrapper.orderByDesc(OrderDO::getCreateTime);
    Page<OrderDO> page = orderMapper.selectPage(
        new Page<>(query.getPageNum(), query.getPageSize()), wrapper);
    return convertToPageResult(page);
}

注意MyBatis Plus有个“字段命名的坑”：如果实体属性是驼峰命名（enter_time对应enterTime），默认开头的驼峰转换在大多数情况下没问题，但如果有特殊自定义字段（比如数据库字段叫user_id，属性叫userId），没开驼峰映射就会查出null。如果属性设置和数据库字段映射不对，优先检查application.yml里是否配置了map-underscore-to-camel-case: true。

统计功能不要走实时查询数据库。如果只是几千条数据无所谓，但既然系统里已经接了Redis，建议每天凌晨把前一天的订单汇总数据算好放到Redis里，管理端展示的时候直接读取，性能上没什么压力，还能顺带展示“缓存优化意识”。

5. 实战中踩过的坑与排查技巧

5.1 SpringBoot 2.x和3.x版本怎么选：别再被“太高版本”卡死了

现在网上很多教程默认SpringBoot 2.7.x，为什么？因为2.7是2.x线的最后一个稳定版本，兼容性最广。SpringBoot 3.x要求JDK 17及以上，而很多学校的教学环境还是JDK 8。选错版本，项目启动直接报“A fatal error has been detected by the Java Runtime Environment”，一脸懵。

我建议做了个筛选：如果你本机的JDK是8，不要追新，直接用SpringBoot 2.7.18；如果你的JDK是17，可以用3.x版本。不要为了“新版”强行换，毕设的核心是把功能做完，不是折腾环境。

SpringBoot 2.7和MyBatis Plus的版本搭配也有讲究。MyBatis Plus 3.5.3以上版本才比较稳定适配SpringBoot 2.x。如果你用了3.5.1或更早版本，可能会出现“mapper接口扫描不到、自动填充失效”等莫名其妙的问题，排查起来非常费时间。

5.2 Lombok和JDK版本冲突：编译环境报错的经典病例

热搜词里有一条“java: you aren't using a compiler supported by lombok”，这个报错很典型。原因是Lombok版本太旧，无法识别新版本JDK的编译器。

解决办法很简单：升级Lombok依赖版本，或者降低JDK版本。如果你在用JDK17，Lombok版本至少要1.18.30以上；如果是JDK8，大部分Lombok版本都能正常工作。

另一个跟JDK相关的坑：“java: 警告: 源发行版 17 需要目标发行版 17”。这是IDEA里Project Structure的SDK设置和Maven的Compiler插件版本不匹配导致的。我的排查顺序是：先看File-Project Structure里的Project SDK，再看Settings里的Java Compiler的Target bytecode version，最后检查pom.xml里maven-compiler-plugin的source和target。这三个地方只要有一个不一致，编译就会报这种错，全部统一成同一个JDK版本就好。

5.3 MySQL时区差8小时：每个后端都会遇到的坑

停车订单涉及入场、出场、支付三个时间点，如果时区配置不对，用户查询账单时会发现时间比实际少了8小时，管理员看统计报表也会错乱。

这个坑的根源在MySQL驱动和连接字符串。8.0版本的MySQL驱动，连接URL里必须加serverTimezone=Asia/Shanghai：

code复制jdbc:mysql://localhost:3306/parking?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

如果用的是SpringBoot，可以在配置项里加：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/parking?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

另外，Java实体类里时间字段建议统一用LocalDateTime，不要用Date，配合Jackson序列化设置时间格式，页面展示就不会乱了。

5.4 循环依赖：SpringBoot 2.6之后默认禁掉了

如果你的Service之间互相注入，比如OrderService注入了SpaceService，SpaceService又注入了OrderService，在SpringBoot 2.6及以上版本启动会直接报错。

这个问题的解决思路有两个方向：一是重构代码，把互相调用的逻辑抽取到第三层，比如新建一个ParkingTransactionService来统一编排；二是临时在application.yml里开启循环依赖：

yaml复制spring:
  main:
    allow-circular-references: true

但我不推荐第二种做法，因为循环依赖本质上是设计缺陷。答辩时如果被问到“怎么解决循环依赖”，你要能说出“我们应该通过重构消除循环依赖，而不是放开开关”，这个回答比“我配置了allow-circular-references”要高级得多。

5.5 Docker部署的常见问题：打包后JDK版本对不上

很多学生会在答辩前把项目打包成镜像部署到服务器上展示。这一步经常出问题，最大的坑是基础镜像的JDK版本不对。

举个例子，你的项目用JDK8编译，但在Dockerfile里用了openjdk:17-jdk作为基础镜像，启动大概率会报“无法加载主类”或“UnsupportedClassVersionError”。

正确的做法是Dockerfile里的基础镜像版本和编译版本保持一致：

dockerfile复制FROM maven:3.8.6-jdk-8 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

FROM openjdk:8-jre-alpine
WORKDIR /app
COPY --from=build /app/target/parking-system.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

用多阶段构建，先编译再运行，既保证镜像体积小，又能保证运行环境和编译环境一致。如果你用的是SpringBoot 3.x，则需要把基础镜像换成eclipse-temurin:17-jre。

5.6 答辩高频提问速查表

这块内容对要答辩的同学来说价值最高，我根据自己的经验整理成了一张表，覆盖了评审老师最常问的问题和思路要点。

答辩的心态上我想多说一句：不要背回答，要把这些逻辑真正理解成自己的东西。评审老师最常拆穿的就是“代码全懂但一换问题就懵”的状态。比如老师追问“如果Redis挂了，你的预约功能还能用吗”，你要能答出“有降级方案，可以退化成数据库事务控制，但并发能力会下降”。

6. 功能扩展：把毕设变成“有亮点”的作品

6.1 让毕设多几个“可讲”的创新点

如果你的时间是两个月，主流程已经搭好，还剩一周左右，不要急着收尾。把下面两个方向其中一个做了，作品质感会提升一个档次。

第一个方向是月卡计费。月卡用户的计费规则和临时车完全不同，不按小时计费，按月扣费，超时可以继续用但需要额外计费。在BillingStrategy里新增一个MonthCardBillingStrategy，然后工厂类里自动识别订单类型。这个方向能体现你对业务规则的理解和策略模式的灵活运用。

第二个方向是车位占用情况统计。在管理端增加一个图表页面，展示最近30天每天的车位占用率、高峰时段分布、收入变化趋势。数据可以直接从订单表里聚合查询，用ECharts画折线图和柱状图。这个功能在答辩演示时的视觉冲击力很强，也能体现你有数据处理和可视化的能力。

6.2 从“能运行”到“能展示”的细节打磨

很多学生项目功能是完整的，但演示时五分钟就翻车了。原因都不是功能逻辑，而是“展示充分性”不足。

我建议在交付前做这三个准备：第一，提前准备好一套完整的演示数据，包括临时车订单、月卡用户、预约超时取消的订单、不同时长的停车记录，这样页面不会空荡荡；第二，录一段两分钟以内的演示视频，万一现场网络出问题，视频也能兜底；第三，系统里准备一个“演示重置”功能，一键清空订单和车位状态数据，方便连续演示多次。

这三个准备看起来不起眼，但实际操作中遇到过太多学生因为现场忘带数据、或者演示到一半状态乱了而翻车，提前把这些问题堵上，体验完全不同。

6.3 这个项目还能延伸出哪些方向

如果你觉得停车场管理系统做得差不多了，想在此基础上做二次延伸，我可以给出几个方向：结合物联网，接入模拟的车辆识别硬件设备，入场出场自动识别车牌，这个在毕设里用摄像头识别车牌或者扫描二维码也能模拟；结合微信小程序，把用户端做成小程序版本，后端接口已经具备了，前端用uni-app或者原生小程序很快就能搭起来；结合数据分析和智能化调度，统计不同时段车位周转率，给出预约价格浮动建议。这些方向都能让你的毕设从“管理系统”升级成“智慧停车平台”，在简历上的描述也会更亮眼。

我自己这些年看过很多学生的毕设项目，最大的体会是：大部分项目不是输在技术难度，而是输在“只做了功能，没做完整”。停车场管理系统这种经典题目，只要把并发控制、状态流转、计费策略这三个点讲明白，你的作品就已经超过同龄人一大截了。剩下的就是踏踏实实把代码写完，把时间花在真正有价值的地方。

最后再分享一个小技巧：项目中每一个核心类都写几行注释，交代清楚“为什么不这么写就会出问题”。这个习惯在答辩前帮了我很大的忙，因为当你面对老师紧张到说不出话时，代码注释就是你的提词器。希望你也能顺利搞定这次毕设，答辩顺利。