卡布斯夫斯基1. 课设/毕设选这个题，我是怎么看它的
先说一下大背景。每年一到选题季，"基于Spring Boot的XXXX系统"这类题目就是绝对的主流，汽车租赁系统更是其中出现频率最高的一档。原因很简单：它既不像电商系统那样业务链路极长，也不像纯CRUD那样毫无区分度，业务上刚好卡在一个"有真实复杂度但又完全可控"的位置，非常适合用来展示你对Spring Boot的理解深度。
很多同学在拿到这个题目之后，第一反应是去搜"汽车租赁系统源码"，然后下载一个跑起来，改改页面上的字，就算交差了。我见过太多这样的项目，答辩的时候连"用户借车之后订单状态是怎么流转的"都说不清楚。所以这篇博文我不打算给你一堆可以直接复制粘贴的代码，而是想把整个系统的设计思路、表结构怎么定、核心业务怎么拆、哪些地方最容易踩坑，从头到尾捋一遍。你跟着这个思路自己写一版，答辩的时候不管老师问什么，你都能接得住。
这个课题的核心价值在于：它是一个典型的多角色、多状态、有时间约束的管理系统。多角色意味着要有权限控制，多状态意味着订单要有一整套状态机，时间约束意味着需要处理租期计算、逾期判断、费用结算。这三个点恰好是Spring Boot项目中非常高频的考察方向，也是以后做企业级项目的基本功。
适合什么人看？正在做这个课题的学生、想拿这个项目练手Spring Boot的初学者，还有想了解租赁类业务系统怎么设计的开发者。下面我按自己实际做这套系统的顺序来讲，从设计到落地，尽量把每个决定的理由也讲清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 设计阶段先把业务边界划清楚：谁在用、用哪些功能、分几步走
拿到题目不要急着建工程，先做需求梳理。这一步决定了后面所有代码的结构，也是论文里"需求分析"章节的素材来源。
2.1 三种角色的权限边界怎么切
汽车租赁系统基本都有三类用户：普通用户（租车人）、门店/后台管理员、系统超级管理员。我见过很多参考代码把角色做得非常随意，用户表里塞一个role字段就结束了，导致后台管理功能全部暴露给普通用户。正确的做法是角色要有清晰的权限边界，而且这个边界最好通过Spring Security来落地，而不是靠前端把按钮藏掉。
普通用户的操作范围：注册登录、浏览车辆和门店、下单租车、支付押金和租金、退车、查看自己历史订单、处理违章记录。后台管理员的范围：管理车辆信息（上架、下架、维护）、处理订单（审核、确认出车、确认还车）、管理门店、处理用户违章。超级管理员则是在管理员基础上增加：创建管理员账号、查看全平台报表、配置系统参数（比如押金比例、逾期费率）。
这么一拆，你其实就知道了：用户表、角色表、菜单/权限表这三张的基础结构是少不了的。很多学生在答辩的时候被问"怎么实现不同角色看到不同菜单"，如果你做了这张表，这个问题就能讲得很具体。
2.2 核心业务流程：从选车到还车，一个订单要经历哪些状态
租赁系统最核心的业务链路是：用户选择取车门店和还车门店、选择车辆、选择租期，系统计算预估价，用户提交订单并支付押金，管理员审核通过，用户到店取车，订单变为"使用中"，到达还车时间后用户到店还车，管理员验车确认，系统根据实际租期和里程计算最终费用，从押金中扣除，剩余退回。如果有超时还车，还要叠加逾期费用。
这个过程里，订单状态至少有这些：待支付、待审核、待取车（已审核通过）、使用中、待结算、已完成、已取消。再加两个异常状态：待处理（还车时有违章或者车辆损坏）、已关闭（超时未取车或者长期未结算）。
我推荐的落地方式有两种：一是用整数字段存状态码，配合常量类做映射；二是用枚举类。我更推荐后者，因为枚举可以在代码里直接绑定状态流转逻辑，比如"当前状态是使用中，才能执行还车操作"，比散落的if-else清晰得多。
2.3 要预留哪些扩展点
做这个课题的时候，十有八九老师会在某个阶段突然加需求。我见过加"优惠券功能"的，加"会员等级折扣"的，加"GPS定位还车"的。虽然不一定都要实现，但你的系统设计要能接得住。这就要求你在车辆表预留状态位、订单表预留费用明细表而不仅仅是总额字段、用户表预留会员等级字段。宁可先多设计一张关联表，也不要把所有信息塞进一个冗余字段里。
3. 数据库设计才是这个项目的重头戏：那些"抄来"的表为什么会出问题
汽车租赁系统的数据库设计，直接决定了你的代码能写得多顺。我用过不少网上下载的SQL脚本，普遍存在一个问题：逻辑上根本走不通。比如没有车辆与门店的关联表、订单表缺少实际的取还车时间导致无法计算逾期、费用字段只有一个总价导致无法拆分租金和押金。
3.1 核心表结构：用户、车辆、门店、订单、费用明细
我给出一个经过实际验证的表结构，包含核心字段和设计理由。
用户表（sys_user）：id、用户名、密码（BCrypt加密）、真实姓名、手机号、身份证号、驾驶证号、角色ID、状态（正常/禁用）、创建时间。这里提一下，身份证号和驾驶证号后期可能会涉及敏感信息加密存储，如果做的是毕业设计，至少要有这个意识。
门店表（business_office）：id、门店名称、城市、详细地址、联系电话、营业时间、状态。车辆归属于某个门店，所以车辆表要带office_id。这里有个容易忽略的点：车辆支持跨门店还车的话，车辆当前所在门店和所属门店是两个概念，需要单独加一个current_office_id。
车辆表（car_info）：id、车辆编号、品牌、型号、车牌号、颜色、座位数、变速箱类型、日租价、押金、所属门店ID、当前门店ID、车辆状态（空闲/已预订/使用中/维修/下线）、行驶里程、车辆图片URL、上架状态。车辆表有两个状态要分开：一个是业务状态，一个是上下架状态，不要混在一个字段里。
订单表（rent_order）：id、订单编号、用户ID、车辆ID、取车门店ID、还车门店ID、计划取车时间、计划还车时间、实际取车时间、实际还车时间、订单状态、租金单价、预计总费用、实际总费用、押金金额、逾期费用、优惠金额、创建时间、审核人、审核时间。这张表是整个系统的主线，字段一定要给足，尤其是"计划时间"和"实际时间"必须分开，不然后面的费用计算全是糊涂账。
费用明细表（order_fee_detail）：id、订单ID、费用类型（租金/押金/逾期费/违章扣款/赔偿金）、金额、状态（冻结/已扣款/已退回）、创建时间、支付流水号。这张表在设计时很容易被忽略，但它恰恰是答辩时非常有区分度的一张表，能说明你考虑了资金安全和对账的问题。
辅助表还包括：角色表、用户角色关联表、菜单权限表、车辆图片表（或者直接放URL字段）、公告表、操作日志表。操作日志表看起来不起眼，但在答辩演示的时候很好用，比如"管理员审核通过了哪一单、是谁操作的"，一查日志就出来了，比空口说"我做了日志功能"更有说服力。
3.2 租期与费用的计算逻辑要先定下来
费用计算是汽车租赁系统的核心规则之一，你在设计数据库的时候就要把规则想清楚。我的规则是这样定的：
预估租金 = 日租价 × 预计租车天数。租车天数按"取车日与还车日之间的自然日差"计算，如果用户是今天14点取车、明天14点还车，算1天；如果是今天取车、后天还车，算2天。有半天租的计费方式吗？多数毕业设计不需要做，因为涉及价格策略的复杂度会陡增，建议不做。
实际租金 = 日租价 × 实际租车天数（按小时取整或按天取整）。这里我用的是"超过1小时按1天计费"，这个规则虽然对用户不够友好，但逻辑最简单、代码最好写，答辩也容易讲清楚。
逾期费 = 日租价 × 1.5 × 逾期天数。押金在订单创建时冻结（模拟），还车结算时先扣租金、再扣逾期费、如果有违章或损坏再扣相应金额，剩余部分退回，费用明细表中对应每条扣款记录。
3.3 索引和约束的考虑
订单表要按用户ID查（用户看自己的历史订单）、按车辆ID查（车辆租赁记录）、按状态查（管理员待办列表），所以这三个字段至少要加普通索引。车辆表的品牌和型号要做搜索的话，也可以加索引。金额字段统一用Decimal，不要用double，否则累计计算会出现精度问题让答辩老师抓到把柄。
约束方面，订单号要做唯一约束，而且不要用自增ID直接暴露给用户，可以用"时间戳+随机数"生成一个业务订单号，看起来更专业。
4. 技术选型与工程初始化：版本怎么配，工程骨架怎么搭才不别扭
4.1 Spring Boot版本的选择逻辑
这个是很多人的第一道坎，尤其是"Spring Boot版本太高"这个搜索词常年挂在热门里。我的建议是：不要追求最新版本。毕业设计/课程设计追求的是稳定，是文档好查、问题好搜、和老师讲的东西对得上。
当前阶段比较稳妥的组合是：Spring Boot 2.7.x + JDK 1.8，或者Spring Boot 3.x + JDK 17。二选一就行，我更推荐前者，原因有三个：一是市面上绝大多数的教程、博客、参考代码都是基于Spring Boot 2.x写的，你遇到问题能搜到答案；二是很多老师的教学环境还是JDK 8；三是2.7.x本身是Spring Boot 2.x的最后一个稳定大版本，正好处在一个成熟期。
Spring Boot 3.x也不是不能用，但它有一些变化要注意：javax包名改成了jakarta、Spring Security 6的配置方式和2.x差异很大、部分第三方starter还没有完全适配。如果你不是特别想拿"使用了最新技术栈"当亮点，真的没必要在版本上给自己制造障碍。
4.2 依赖清单和POM里最容易犯的错
我的pom.xml核心依赖如下：spring-boot-starter-web、spring-boot-starter-security、spring-boot-starter-validation、mybatis-plus-boot-starter（或spring-boot-starter-jdbc + mybatis）、mysql-connector-java、lombok、jjwt（用于JWT）、hutool（工具类库，可选）、spring-boot-starter-test。
容易犯的错有三个：一是lombok版本和JDK版本不匹配导致注解不生效；二是mysql驱动坐标写错（Spring Boot 2.7.x中要用mysql:mysql-connector-java，坐标带版本号，5.1.x和8.0.x的驱动Class.forName写法不同）；三是mybatis-plus和Spring Boot版本不匹配导致启动报错。
4.3 application.yml的配置习惯
一个很典型的问题：application.yml 文件在IDEA里没有语法提示。这个大概率是缺少Spring Boot配置文件处理器依赖，在pom里加上spring-boot-configuration-processor就好了，这个坑特别常见，搜"IDEA中Spring Boot项目的application.yml不提示"能搜到一堆帖子。
application.yml分环境配置也很重要，我至少会拆成application-dev.yml和application-prod.yml，开发环境数据库连本地，生产环境连云服务器。在application.yml里通过spring.profiles.active=dev切换。答辩的时候老师问你"怎么部署的"，你随口就能说出这套配置分离的思路，加不少印象分。
数据库连接串的时区问题也要设置好，serverTimezone=Asia/Shanghai必须写上，否则连MySQL 8会报时区错误。另外useSSL=false也建议加上，避免本地环境出现SSL握手警告。
4.4 启动类扫描路径的坑
用了MyBatis-Plus的话，启动类上要加@MapperScan("com.xxx.mapper")，不然Mapper接口根本注入不进来。很多人的项目报"Field xxxMapper in ... required a bean of type ... that could not be found"，十有八九就是这个原因。如果你不想用@MapperScan，也可以在每个Mapper接口上加@Mapper注解，但这样比较啰嗦，不推荐。
还有，启动类要放在包结构的最外层。比如你的包名是com.car.rental，启动类就必须直接放在com.car.rental下，否则Spring Boot的默认组件扫描路径只会扫描启动类所在包及其子包，你放在别的包下的Controller和Service就全部注入失败。
5. 核心功能实现：登录鉴权、租还车流程、数据看板
5.1 Spring Security + JWT的登录鉴权怎么做最省事
登录鉴权是汽车租赁系统的门面功能，也是答辩老师必问的模块。我的方案是：Spring Security负责请求拦截和密码校验，JWT负责无状态会话管理。
实现思路是这样的：
- 用户提交用户名和密码，后端调用
AuthenticationManager.authenticate()做校验。 - 校验通过后，用
Jwts.builder()生成一个token，把用户ID、用户名、角色ID放进去，设置过期时间（比如24小时）。 - 前端把token存在localStorage（示例项目这样够用），每次请求在header里带
Authorization: Bearer <token>。 - 后端写一个JWT过滤器，继承
OncePerRequestFilter，在每个请求进来时解析token，把用户信息放进SecurityContext。 - SecurityConfig里放行登录接口、注册接口、车辆列表查询接口（用户未登录也能浏览车辆），其他接口全部要求认证，并通过
@PreAuthorize("hasRole('ADMIN')")之类的注解做角色控制。
这里有个细节：SecurityConfig里放行的接口路径和Controller里@RequestMapping的路径必须完全一致，包括上下文路径。如果你配了server.servlet.context-path，Security的放行路径里记得加上前缀，否则就会出现"登录接口一直403"的问题。
JWT密钥不要硬编码在代码里，放到application.yml中，答辩的时候也可以顺带提一句"密钥可以配置化，生产环境建议用更复杂的密钥管理方案"，显得有安全意识。
5.2 订单状态流转：用状态机思维替代散乱的if-else
前面提到了订单状态字段，这里说具体怎么实现。核心是写一个订单状态流转的服务方法，比如changeOrderStatus(orderId, expectedStatus, targetStatus)，修改前先校验当前状态是不是expectedStatus，是才允许变更，不是就抛出业务异常。
一个还车的例子：
java复制@Transactional
public void returnCar(Long orderId, Integer mileage) {
RentOrder order = rentOrderMapper.selectById(orderId);
if (order == null) {
throw new BizException("订单不存在");
}
// 当前状态必须为使用中
if (!OrderStatus.IN_USE.equals(order.getStatus())) {
throw new BizException("当前订单状态不允许还车");
}
// 计算实际费用
BigDecimal actualRent = calculateRent(order);
BigDecimal overdueFee = calculateOverdueFee(order);
// 扣款逻辑：从押金中扣，剩余退回
BigDecimal totalDeduct = actualRent.add(overdueFee);
// ... 生成费用明细记录
// 更新车辆状态为空闲
carInfoMapper.updateStatus(order.getCarId(), CarStatus.FREE);
// 更新订单状态为待结算
updateOrderStatus(order, OrderStatus.IN_USE, OrderStatus.PENDING_SETTLEMENT);
}
把这套逻辑写在一个事务方法里，配合@Transactional保证数据一致性。一旦中间任何一步抛异常，整个方法回滚，不会出现"订单状态改了但车辆状态没改"的脏数据。
5.3 车辆检索和门店/品牌筛选的实现
车辆列表不能只是简单的select * from car_info，至少要支持按条件查询：品牌、车型、座位数、取车门店、可租日期。日期条件相对复杂，因为一辆车在某段时间被租了，理论上就不应该出现在结果里。最简单的实现是：当前状态为"空闲"的车辆直接展示；"已预订"的车辆如果预订时间段与查询时间段不冲突，也可以展示。这个判断用SQL写起来比较复杂，我的实现方式是在Java层做过滤：先把候选车辆查出来，再用时间段重叠判断去掉冲突项。
时间段重叠的判断逻辑是：
code复制旧订单的取车时间 < 查询的还车时间 && 旧订单的还车时间 > 查询的取车时间
这个公式同时满足才说明两个时间段重叠。很多学生会在这里写反，把"或"当成"与"，导致查出来的车辆列表一团乱。
5.4 后台数据看板：让系统"看起来"完整但不用太复杂
毕业设计里加上数据统计页面，会给整体印象加分不少。我用的是ECharts + 后端聚合查询。首页展示：本月订单总数、本月营收、在租车辆数、车辆总数；ECharts图表展示近7天订单趋势、热门品牌Top5、门店订单占比。后端就是几条带GROUP BY的SQL，前端用ECharts的柱状图、饼图、折线图渲染一下，技术难度并不高，但视觉效果非常直观。
6. 事务、循环依赖、单元测试：开发中遇到的几个典型问题
6.1 @Transactional失效的几个场景
Spring Boot的事务失效是个老生常谈的话题，但我发现很多学生在做这个课题时还在踩同一个坑：在同一个类内部调用带@Transactional的方法，事务是失效的。原因很简单：事务是通过代理对象实现的，而this.xxx()调用的是原始对象，不经过代理，所以注解不生效。
典型场景比如：在OrderService里，createOrder()调用了同类里的deductStock()，后者上有@Transactional。看起来deductStock在事务里，但实际上完全没有。解决办法是：把需要事务的方法拆到另一个Service里，或者注入自身代理，或者通过TransactionTemplate手动控制事务。
第二个常见问题是：RuntimeException才能触发回滚，checked exception不会。默认情况下Spring事务只对RuntimeException和Error回滚。如果你在某处catch了异常但没有重新抛出，事务自然也不会回滚。所以要么不catch，要么catch后手动TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。
6.2 循环依赖的处理
循环依赖的经典案例：OrderService依赖UserService，UserService又依赖OrderService。Spring Boot 2.6之后默认禁止循环依赖，启动直接报错。如果你在网上搜到"设置spring.main.allow-circular-references=true"的解决办法，那只是饮鸩止渴，真正的解法是重构：把两个Service共同依赖的部分抽到第三个Service里，或者改成单向依赖。
6.3 给关键业务逻辑写单元测试
我建议至少给费用计算、订单状态流转、权限校验这三块写单元测试。费用计算是纯逻辑，最容易出bug；状态流转涉及数据库状态变更，可以用@SpringBootTest + H2内存数据库或者直接用本地MySQL测试。用MockMvc测Controller的登录和查询接口也不难。答辩的时候问一句"你的系统测过吗"，你就能说"我写了单元测试覆盖了什么场景"，这比"我手动试过能跑"强太多了。
6.4 关于MyBatis-Plus的使用建议
如果你用的是MyBatis-Plus，我建议你：实体类用@TableName和@TableId标明表名和主键策略，逻辑删除用@TableLogic（这样删除车辆是软删，历史订单还能关联上），自动填充用MetaObjectHandler把创建时间、更新时间统一处理了，不要在每一个insert里手动set时间。
但也不要过度依赖MyBatis-Plus的selectPage默认分页，当你的查询有复杂的多表关联时，还是要自己写XML里的SQL。汽车租赁系统的订单列表十有八九要关联用户表查用户名、关联车辆表查车牌号，这种场景直接用LambdaQueryWrapper不太优雅，写XML里的<resultMap>更清晰。
7. 从本地到公网部署：前端、后端、数据库怎么放
7.1 打包前的配置检查和常见报错
打包之前，建议先把application-prod.yml的数据库连接改成生产环境数据库地址，把JWT密钥换成一个足够长的随机字符串。然后把spring-boot-maven-plugin配置好，用mvn clean package构建出jar包。
如果你是Spring Boot 2.7 + JDK 1.8组合，构建时偶尔会遇到"无效的目标发行版"之类的报错，一般是IDE的Java compiler版本和pom里的java.version不一致，把Project Structure里的SDK和Language level统一成1.8即可。
7.2 JDK 1.8打包到Docker Desktop的完整过程
现在很多人的电脑装的是Docker Desktop，用Docker部署确实比较干净，也能在答辩环境里快速演示。我用的是多阶段构建，这样镜像干净，还能保证JDK环境正确。
一个可以用的Dockerfile写法：
dockerfile复制# 第一阶段：构建
FROM maven:3.8.4-openjdk-8 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn clean package -DskipTests
# 第二阶段：运行
FROM openjdk:8-jre-alpine
WORKDIR /app
COPY --from=builder /app/target/car-rental.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar", "--spring.profiles.active=prod"]
构建命令：docker build -t car-rental:1.0 .，运行命令：docker run -d -p 8080:8080 --name car-rental car-rental:1.0。注意Docker Desktop的端口映射，如果8080被占用，改成-p 8081:8080。
如果是前后端分离项目，前端可以单独用Nginx部署，后端只暴露接口。但毕业设计为了省事，也可以直接把前端打包后的dist文件放到Spring Boot的src/main/resources/static下，打成同一个jar包，访问8080端口就是完整系统。这种方式演示起来最方便，一个docker run就把整个系统拉起来了。
7.3 部署过程中的常见坑
部署阶段常见的坑是：本地跑得好好的，部署到服务器/Docker里就各种问题。最典型的是端口没开放、防火墙拦截、数据库连接串的host写成了localhost。注意：在Docker容器里访问宿主机MySQL，localhost指向的是容器自己，要改成host.docker.internal（Docker Desktop支持）或者宿主机IP。
还有一个就是静态资源路径大小写问题。Linux文件系统区分大小写，Windows不区分，本地访问没毛病，服务器上图片加载404，根因可能就是uploads/和Uploads/不一致。
7.4 演示环境的准备建议
答辩前我强烈建议准备好一套完整的演示数据，包括：若干车辆信息（不同类型、不同价格带）、若干门店、一个管理员账号、一个普通用户账号、几条不同状态的订单（待审核、使用中、已完成）。这样答辩时演示"查看订单流程"、"处理还车"才有素材，不用现场吭哧吭哧地下单，浪费时间还容易紧张。
8. 几位答辩老师最爱追问的问题，提前想好答案
答辩环节的体验很大程度上决定你的分数，这里列几个高频追问，都是我实际听到过的。
问1：你的系统怎么保证数据一致性？ 答：核心的租还车流程方法上加了@Transactional，一旦中间步骤抛异常，整个操作回滚，不会出现订单状态和车辆状态不一致。同时关键操作都有操作日志记录。
问2：如果同一辆车在同一个时间段被两个人下单怎么办？ 答：两个方面。一是数据库层面，车辆表的状态字段在"空闲"状态下才允许创建订单，创建订单时把车辆状态改成"已预订"，更新语句里带WHERE status = 'FREE'，如果更新影响行数为0，说明车辆已被人抢订，则抛出提示。二是在订单表增加唯一约束或者时间段检查逻辑，这个用SQL不好做的话，也可以在应用层加分布式锁或者乐观锁，在压测/并发场景下可以进一步优化。
问3：密码存的是什么？ 答：使用的是BCrypt加盐哈希，不是明文，也不是简单的MD5。即便数据库泄露，也不能直接还原出原始密码。
问4：前端页面是你自己写的吗？ 答：用的是目前主流的Vue3 + Element Plus进行开发，模板页面是参考了Admin框架的结构，但具体的业务逻辑、数据对接、权限控制是自己完成的。如果你后端技术本身扎实，这样回答完全没问题，不要硬吹"所有页面UI都是自己画的"。
问4b：为什么用Spring Boot而不是SSM？ 答：Spring Boot简化了项目的配置和启动流程，内嵌Web容器方便独立部署，生态成熟，自动装配机制也降低了集成各种第三方框架的复杂度。SSM时代大量的XML配置在Spring Boot中大多通过约定大于配置的方式自动完成了。
问5：你的数据库为什么这么设计？ 答：比如订单表把计划时间和实际时间分开，是考虑到实际场景中用户可能提前还车或延迟还车，费用结算需要基于实际时间计算。费用明细表独立出来，是为了每一笔扣款和退款都有据可查，这是参考了支付系统的对账思路。
9. 一些我对这个课题的个人看法和扩展建议
如果让我给这个课题排一个优先级，我会这么排序：数据库设计 > 订单完整流程 > 权限控制 > 租还车费用计算 > 前端页面 > 部署演示。前四者是系统的灵魂，后面两者是锦上添花。很多同学把大量时间花在调前端样式的炫酷效果上，结果核心流程跑不通，或者答辩被问到业务逻辑时支支吾吾，这是本末倒置的。
另外，如果你想在这个题目上做出亮点，我建议找一个方向稍微深入一点。比如：把还车逾期费用做成按小时递增的阶梯价格，并解释为什么这样设计；或者在押金退费环节模拟了真实支付回调和退款的状态流转；又或者在车辆列表搜索时引入了简单的全文检索或条件组合查询。不用多，一个点深入就够了，论文里可以专门拿出一节来写，答辩时也有可以深入展开的素材。
最后再分享一个写论文阶段的小技巧：每写完一个模块就去截图，标注关键设计，存到论文素材文件夹里。不要等全部写完再去补截图，到那时前端页面改版了、数据变了，去数据库临时造数据非常痛苦。我当年就是这么干的，最后写论文的时候特别快，平时随手保存的代码片段和截图全派上了用场。