Spring Boot二手车交易系统毕业设计：从技术选型到答辩避坑指南

简介面向Java毕业设计与课程作业的完整项目资料基于SpringBootVue实现雪都出行二手车交易系统涵盖用户端、管理员端及数据库设计。开发环境为IDEA、JDK1.8、Tomcat8.5、MySQL5.7前端采用Vue与CSS后端为SpringBoot框架系统功能包括二手车检索、特价锁定、定金支付、收藏评价、历史记录查询、管理端促销设置与用户推送等适合学习前后端分离项目实战、订单流程及权限管理。压缩包共1177个文件以JS、HTML、CSS等前端资源为主含45个Java源文件、4个Vue组件、SQL脚本及工程配置相关文件整体约22.82MB结构覆盖源码、论文、开题报告与答辩PPT。已有37人学习随包附完整论文与答辩PPT可直接用于毕设参考或二次开发帮助快速理解二手车交易系统的业务逻辑与SpringBoot整合实践。1. 大四做《雪都出行》二手车交易系统先搞懂这个毕设到底要你交付什么找我咨询“基于Spring Boot的二手车交易系统”这类项目的人一大半是卡在毕业设计上的学生。标题里的《雪都出行》名字听着像商业平台但落到论文和开题报告里它就是一个典型的Java Web管理系统前端展示二手车源后端管车辆、订单、用户再套一层管理员后台。Spring Boot负责把后端服务跑起来MySQL存业务数据MyBatis Plus或JPA操作数据库前端用Vue或Thymeleaf都行最后交一份论文、开题报告和答辩PPT。这类系统最大的价值不是“做出一个能上线的二手车商城”而是把大学四年学到的Java、Spring、数据库、前端知识串成一条完整的闭环。你答辩時要说清楚为什么用Spring Boot而不是SSH表结构怎么设计才能支持车辆上下架和订单流转用户登录的Token怎么生成和校验。这篇笔记就按我平时帮学生梳理项目的老路从选型讲到落地再讲到论文和答疑怎么准备全程可复现。适合谁看正在做这个题目、或者想用“二手物品交易”类题目替代的学生以及需要快速搭建演示系统的开发者。我会刻意避开那些花哨的微服务和高并发设计因为毕业设计最怕的就是——架构讲得飞起代码一跑就崩。2. 技术选型与核心原理为什么Spring Boot是这类项目的“默认答案”2.1 Spring Boot相比SSH和SSM到底赢在哪早几年做Java Web毕设主流是SSHStruts2SpringHibernate或者SSMSpringSpringMVCMyBatis。SSH如今已经很少人用了SSM还有不少学校在教但Spring Boot近五年基本成了默认选择。核心原因不是Spring Boot性能更强而是它把“配置”这个最劝退的环节砍掉了。以数据源配置为例传统SSM你要写applicationContext.xml、spring-mvc.xml、mybatis-config.xml三个文件还要处理各种bean的注入关系Spring Boot只需要一个application.yml里面写上数据源地址、用户名、密码再加一个MapperScan注解就完事了。内嵌Tomcat也省掉了单独部署WAR包的步骤mvn spring-boot:run一键启动。如果你翻开源码看Spring Boot的自动配置原理也不算黑匣子spring-boot-autoconfigure包里的META-INF/spring.factories文件声明了所有候选配置类启动时通过EnableAutoConfiguration按条件加载。毕设答辩如果被问到“自动配置怎么实现”能说出“ConditionalOnClass和ConditionalOnMissingBean两个注解配合”就够用了。2.2 数据模型设计二手车交易系统的五张核心表系统设计的第一步不是写代码而是画ER图。我的习惯是把业务拆成五个核心模块用户管理、车辆管理、订单管理、收藏管理、管理员后台。对应的表结构如下tb_user用户表。字段包括user_id主键、username、passwordBCrypt加密后的密文、phone、avatar、role区分普通用户和管理员。tb_car车辆表。包含car_id、title标题、brand品牌、model车型、price售价、mileage里程、year上牌年份、status0下架 1上架 2已售、seller_id卖家用户外键、description描述文本。tb_order订单表。order_id、car_id、buyer_id、seller_id、order_status0待付款 1待过户 2已完成 3已取消、create_time、pay_time。tb_favorite收藏表。id、user_id、car_id、create_time建唯一索引(user_id, car_id)避免重复收藏。tb_admin管理员表。单独建表不要混在用户表里权限隔离更清爽。这五张表看起来简单但是有坑。比如车辆表为什么不直接放一个owner_id而叫seller_id因为一辆车在系统里可以经历“上架-售出-再次上架”的过程订单表里的seller_id才是当前卖家而车辆表保留首次发布者信息容易造成业务混乱。我就是在这上面吃过亏——第一次设计时一张车辆表挂了两个用户外键结果写SQL查询时总是搞混谁是谁最终统一原则车辆表只负责“车”的属性交易关系全部放订单表。2.3 权限与登录验证JWT还是Session很多学生做登录功能习惯用Session因为老师上课讲的就是Session。但在Spring Boot项目里我更推荐用JWTJSON Web Token做无状态登录理由有三个前后端分离时Session跨域麻烦JWT天然适配移动端答辩时能体现你对无状态认证的理解。JWT的实现套路是用户登录成功后后端用jjwt库生成一个包含用户ID和角色的Token签名密钥放在application.yml里前端每次请求在Authorization头带上这个Token后端用一个拦截器解析Token解析成功就把用户信息放进ThreadLocal或请求上下文失败直接返回401。// JwtUtils.java —— 生成和解析Token的工具类 public class JwtUtils { // 密钥实际项目中从配置读取不要硬编码 private static final String SECRET_KEY your-secret-key-change-in-production; private static final long EXPIRE_TIME 7 * 24 * 60 * 60 * 1000; // 7天有效期 public static String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setExpiration(new Date(System.currentTimeMillis() EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); } }这段代码的逻辑generateToken把用户ID作为主题subject角色放进自定义claim再设置过期时间最后用HS256算法签名。parseToken在拦截器里被调用返回的Claims里就能取出用户ID和角色。这里有两个参数要说明密钥SECRET_KEY在开发环境随便写但部署时务必用环境变量注入否则源码泄露等于所有Token都失效过期时间EXPIRE_TIME设7天是为了兼顾用户体验和安全如果你做的是后台管理系统建议缩短到2小时配合Redis实现“记住我”的续期逻辑。拦截器的编写注意一个坑不要拦截登录接口本身。我见过有学生把拦截器配置成/*结果登录请求也被拦了每次调登录接口都报401半天找不到原因。// AuthInterceptor.java —— 关键代码白名单放行 public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 如果是OPTIONS预检请求直接放行 if (OPTIONS.equals(request.getMethod())) { return true; } String token request.getHeader(Authorization); if (token ! null token.startsWith(Bearer )) { try { Claims claims JwtUtils.parseToken(token.substring(7)); request.setAttribute(userId, claims.getSubject()); request.setAttribute(role, claims.get(role)); return true; } catch (Exception e) { response.setStatus(401); return false; } } response.setStatus(401); return false; }2.4 车辆检索不要一上来就上Elasticsearch业务里最常被问到的功能是“搜索车辆”。很多同学看了些博客答辩PPT里写着“基于Elasticsearch的全文检索”但实际上项目里连ES都没装。我建议毕设项目的搜索老老实实用MySQL的LIKE模糊查询理由很简单你的数据量撑死几千条LIKE查询走全表扫描也就几毫秒而引入ES意味着要多部署一个服务、多写一套同步逻辑一旦PPT上写了但演示时ES没启动那就是自曝翻车现场。车辆搜索的SQL设计要注意索引。品牌和车型用等值查询加普通索引标题和描述用模糊查询不加索引。价格区间和上牌年份用范围查询。把条件拼接放在Service层做控制好and和or的优先级。-- 车辆条件查询SQLMyBatis XML中实现 SELECT car_id, title, brand, model, price, mileage, year, status FROM tb_car WHERE status 1 if testbrand ! null and brand ! AND brand #{brand} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR model LIKE CONCAT(%, #{keyword}, %)) /if ORDER BY create_time DESC LIMIT #{offset}, #{pageSize}这个SQL的核心设计思想是动态拼接有参数才加条件没参数就全查配合前端的分页组件刚好形成“条件筛选分页”的完整链路。注意MyBatis里小于号要用lt;转义否则XML解析会报错LIMIT #{offset}, #{pageSize}是MySQL的分页写法如果你用PageHelper插件则可以直接传页码但原理一样是拦截SQL拼接LIMIT。3. 跑通核心流程从车辆上架到订单完成的三段式代码3.1 车辆上架文件上传与数据入库的注意点车辆发布功能是“卖家端”的核心。前端表单一般长这样车源标题、品牌下拉框、车型、上牌年份、表显里程、售价、车况描述、以及多张车辆图片。图片上传是这里最麻烦的部分因为涉及文件存储路径、大小限制、格式校验。Controller层接收MultipartFile数组把文件保存到本地磁盘并将访问URL存入数据库。实际部署时要注意本地路径写成绝对路径会翻车因为不同环境你的项目位置不一样最好用配置项动态读取。// CarController.java —— 发布车辆的接口实现 PostMapping(/publish) public Result publishCar(RequestBody CarPublishDTO dto) { // 从请求上下文中获取当前登录用户ID Long userId (Long) request.getAttribute(userId); Car car new Car(); car.setTitle(dto.getTitle()); car.setBrand(dto.getBrand()); car.setModel(dto.getModel()); car.setPrice(dto.getPrice()); car.setMileage(dto.getMileage()); car.setYear(dto.getYear()); car.setDescription(dto.getDescription()); car.setSellerId(userId); car.setStatus(1); // 1已上架 car.setCreateTime(new Date()); carMapper.insert(car); return Result.success(发布成功); } // FileUploadController.java —— 图片上传 PostMapping(/upload) public Result uploadFile(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(文件不能为空); } // 校验文件大小建议不超过2MB if (file.getSize() 2 * 1024 * 1024) { return Result.error(图片大小不能超过2MB); } // 校验扩展名 String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); ListString allowedExt Arrays.asList(.jpg, .jpeg, .png, .webp); if (!allowedExt.contains(ext.toLowerCase())) { return Result.error(仅支持jpg、png、webp格式); } // 新文件名用UUID避免重名覆盖 String newFileName UUID.randomUUID().toString() ext; // 存储路径从配置项读取不要写死 String uploadDir uploadConfig.getPath(); File dir new File(uploadDir); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(uploadDir newFileName)); String url /images/ newFileName; return Result.success(url); }这里两个方法的职责是分开的发布车辆只负责把表单数据写入tb_car表图片则先上传拿到URL再传给发布接口。很多同学会把图片的base64编码字段直接存数据库这是最差的做法——数据库变得臃肿不说查询车辆列表时几张图片就能拖慢接口好几倍。正确做法是存URL路径静态资源映射由Spring Boot的WebMvcConfigurer配置// WebConfig.java —— 映射本地图片路径为虚拟URL Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadConfig.getPath()); } }3.2 下单购买状态机思维是这一节的重点二手车交易的下单流程比普通商品多一个“线下过户”的概念所以订单状态我设计了四个0待付款 - 1待过户 - 2已完成 - 3已取消。下单时要同时做几件事校验车辆状态是1上架中把车辆状态改成2已售然后插入一笔订单。这三步必须放在同一个事务里否则会出现“车卖出去了但订单没生成”或者“订单生成了但车还在架子上”的数据不一致问题。// OrderService.java —— 创建订单的核心方法 Transactional(rollbackFor Exception.class) public Long createOrder(Long carId, Long buyerId) { // 1. 查询车辆并加锁避免并发下单 Car car carMapper.selectByIdForUpdate(carId); if (car null) { throw new BusinessException(车辆不存在); } if (!Integer.valueOf(1).equals(car.getStatus())) { throw new BusinessException(车辆已下架或已售出); } // 2. 创建订单 Order order new Order(); order.setCarId(carId); order.setBuyerId(buyerId); order.setSellerId(car.getSellerId()); order.setOrderStatus(0); // 待付款 order.setCreateTime(new Date()); orderMapper.insert(order); // 3. 车辆标记为已售 car.setStatus(2); carMapper.updateById(car); return order.getOrderId(); }注意selectByIdForUpdate这里用了悲观锁在MySQL的InnoDB引擎下会对这行记录加写锁直到事务提交。对于毕设项目来说用悲观锁比用乐观锁更直观答辩时也能解释清楚“为什么这里不用Redis分布式锁——因为单机应用用不上数据库锁已经足够”。订单状态流转用状态机管理前端操作触发对应接口用户点“取消订单”状态从0跳到3用户点“确认收货完成”状态从1跳到2卖家点“确认已过户”状态从0跳到1。每个动作都要在Service层校验当前状态是否合法。比如订单已经是“已完成”就不能再取消。硬编码的状态判断容易写成一团乱麻我的建议是单独建一个OrderStatus枚举类把所有允许的状态转换关系集中管理后边接支付回调或者管理员修改订单时只需要查这张转换表就行。3.3 管理员后台图表统计的SQL怎么写才能让答辩眼前一亮管理员后台常常是拉开档次的地方。别人只做增删改查你如果多一个“数据统计看板”答辩时印象分会高不少。统计维度一般有每日订单量、车辆品牌分布、价格区间分布、用户注册趋势。订单量统计的SQL要按日期分组SELECT DATE(create_time) AS day, COUNT(*) AS order_count FROM tb_order WHERE create_time #{startDate} GROUP BY DATE(create_time) ORDER BY day品牌分布统计SELECT brand, COUNT(*) AS car_count FROM tb_car GROUP BY brand ORDER BY car_count DESC LIMIT 10前端用ECharts画柱状图和饼图数据从后端接口拉JSON格式类似[{day: 2025-03-01, order_count: 3}]。这个组合实现难度不高但视觉效果好也是论文里“系统实现”一章的好素材。需要注意SQL里日期函数在不同数据库下有差异——MySQL用DATE()PostgreSQL用DATE_TRUNC()别写混了。4. 避坑与常见问题Spring Boot二手车交易系统的7个翻车现场4.1Mapper接口扫不到启动直接报Invalid bound statement现象Spring Boot项目启动成功但一调用Mapper接口方法就报org.apache.ibatis.binding.BindingException。 原因MyBatis的Mapper接口和XML文件没有建立映射常见情况有两种——XML文件没有放在resources目录下对应的包路径里或者application.yml里没有配置mybatis.mapper-locations。 解决检查src/main/resources/mapper目录下是否有对应的XML文件然后在配置里加上mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.entity另外接口和XML的namespace必须一致方法ID要和接口方法名一致。这听起来是废话但真有人因为XML文件名写错了找了一下午bug。4.2 前端跨域请求失败浏览器控制台报CORS错误现象Vue前端跑在localhost:8080Spring Boot跑在localhost:8081请求接口时浏览器报No Access-Control-Allow-Origin header is present。 原因前后端分离部署端口不同属于跨域后端没有允许跨域的响应头。 解决加一个CORS配置类或者直接在Controller上加CrossOrigin。全项目的跨域配置我一般这样写Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns是Spring Boot 2.4以上版本才有的写法老版本用allowedOrigins。如果你用了JWT拦截器还要记得放行OPTIONS预检请求否则浏览器预检直接被拦截器拦掉接口照样调不通。4.3 时间字段差8小时现象数据库存的时间是2025-06-01 12:00:00前端显示成2025-06-01 20:00:00或者反过来。 原因JVM默认时区用的是系统时区MySQL连接串里没有指定serverTimezoneJackson序列化时按GMT转换。 解决三处统一。application.yml里给JDBC连接串加参数同时设置Jackson时区spring: datasource: url: jdbc:mysql://localhost:3306/car_trade?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jackson: time-zone: GMT8 date-format: yyyy-MM-dd HH:mm:ss4.4 JWT密钥硬编码在代码里现象项目提交到Git仓库Token密钥被同学看到理论上可以伪造Token访问任意用户数据。 原因开发图方便把密钥写在常量类里。 解决用ConfigurationProperties读取环境变量或者放到application-prod.yml里并配置为环境变量引用。4.5 车辆上下架扫描不到“数据权限”现象卖家能看到别人发布的车辆的“上下架”按钮一按就把别人的车下架了。 原因后台接口只做了登录验证没做资源归属校验。 解决在Service层加一行校验——当前操作用户ID必须等于车辆seller_id否则抛出无权限异常。这个坑在答辩演示时一旦被发现印象分会掉很多因为这是明显的越权漏洞。4.6 MySQL连接数被测试工具打满现象用JMeter压测或者前端页面频繁刷新后端日志报Too many connections。 原因连接池默认配置太小或者代码里忘记释放连接用MyBatis Plus一般不会但手动用JDBC操作时容易犯。 解决明确用HikariCP配置最大连接数同时排查代码里是否在循环中调用Mapper方法。spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 300004.7 论文中写了“前后端分离”但项目其实是Thymeleaf现象PPT和论文声称是前后端分离架构源码却是后端返回ModelAndView配合Thymeleaf模板。 原因一开始想做前后端分离后来图省事改回模板渲染。 解决二选一并统一口径。选了前后端分离前端就老老实实起Vue项目所有接口返回JSON选了传统架构论文里就别出现“Vue”“前端工程化”这些词。最怕内容是混着来的答辩老师如果追问几个前后端数据交互问题很容易露馅。5. 把项目写进论文与开题如何把《雪都出行》包装成一份有说服力的文档5.1 一篇合格的毕业论文要包括哪些部分很多学生写论文是最后一星期赶出来的结构跟流水账一样。正常的软件工程类毕业设计论文包含七章第一章绪论写研究背景和意义。背景不能只写“随着二手车市场的发展”这种空话而是结合具体数据比如“中国二手车年交易量已突破千万辆级别但传统线下交易存在信息不透明、中间商赚差价等问题”再引到“设计一个线上平台来解决”。 第二章相关技术介绍写Spring Boot、MySQL、Vue、ECharts等技术的特点和选型理由。 第三章系统需求分析分功能性需求和非功能性需求。功能需求画用例图包含用户、卖家、管理员三个角色非功能需求写性能接口响应时间不超过200ms、安全密码加密存储、易用性。 第四章系统设计包含架构图、功能模块图、数据库ER图、核心表结构说明。这一章是文档的重点图要清晰数据库表字段要完整。 第五章系统实现按模块写核心代码配运行截图。代码不要大段粘贴截取关键逻辑给出解释。 第六章系统测试写测试用例表格和测试结果。 第七章总结与展望这一段有个写作技巧——不要只说自己做了多少功能更要写“系统存在的不足”比如缺少在线支付、图像识别车况等展望写将来可以怎么改进。答辩老师看了会觉得你有思考深度。开题报告的核心是“选题意义”和“研究内容”。选题意义可以引用行业报告的数据研究内容按模块罗列最后加一个进度安排表格按周拆任务第一二周需求分析第三四周技术学习第五至八周编码实现第九十周测试第十一周论文初稿第十二周修改答辩。5.2 PPT怎么做出答辩的节奏感答辩PPT和论文是互补关系不是把论文复制一遍。我的经验是15页左右按这个节奏来第1页封面标题加姓名学号指导老师。 第2页目录四五个大块就行别列十几条。 第3-5页选题背景与研究意义讲清楚你为什么要做这个系统配市场需求数据图表。 第6页技术选型一张架构图说明Spring Boot Vue的请求链路。 第7-8页系统需求分析用例图加核心功能列表。 第9-10页系统设计展示数据库ER图和核心表。 第11-13页系统实现挑三个最有代表性的功能页面截图比如车辆列表页、下单页、管理后台统计看板配合简短说明。 第14页系统测试放测试用例表和结果。 第15页总结与展望说不足和改进方向。答辩时有个技巧提前准备几个可能被追问的问题。比如“为什么选MySQL不选Oracle”回答“开源免费、生态好、满足需求”就好“如何保证数据一致性”回答“事务控制加状态机操作都走Service层统一管理”。千万别在PPT上写自己没做过的东西——答辩老师特别喜欢追问你PPT上的每一张图。5.3 论文查重怎么降论文里技术介绍部分最容易查重标红因为Spring Boot、MyBatis这些名词解释网上到处都是。我的经验是“用自己的话说”。先读两三篇相关论文或博客合上屏幕用自己的话把技术特点写出来写的时候加进自己的项目语境比如“在本系统中Spring Boot负责……”。代码段一般不在查重范围内但注释可能被算进去注释也尽量自己写。6. 进阶技巧给系统加一个“在线估价”功能用到的算法和架构值得写进答辩如果想让《雪都出行》在答辩时比其他同学的同质化题目高半档建议加一个“车辆估价”模块。这个模块不一定多复杂但能体现你用算法解决实际问题的能力。我当初给一个朋友的项目加了这个功能答辩老师当场就问了不少问题效果非常好。估价的核心逻辑是参考“同年份同品牌同车况的近期成交价”。数据来源可以在系统里人工录入几百条历史成交记录算法用最简单的特征加权回归。车辆价格受多个因素影响品牌影响系数豪车和国产车差异很大、年份折旧率第一年折价15%之后每年递减、里程损耗每万公里减一定金额、车况评级优/良/差三档调整系数。// CarValuationService.java —— 简单估价算法实现 public BigDecimal estimatePrice(CarEvaluationParam param) { // 1. 同品牌同年份的历史成交均价作为基准价 BigDecimal basePrice carMapper.selectAvgPriceByBrandAndYear( param.getBrand(), param.getYear()); if (basePrice null) { basePrice carMapper.selectAvgPriceByBrand(param.getBrand()); } if (basePrice null) { throw new BusinessException(暂无可参考的历史成交数据); } // 2. 里程折旧每1万公里减0.5% BigDecimal mileageFactor BigDecimal.ONE .subtract(param.getMileage().divide(new BigDecimal(10000), 2, RoundingMode.HALF_UP) .multiply(new BigDecimal(0.005))); // 3. 车况系数优1.05 良1.0 差0.9 BigDecimal conditionFactor; switch (param.getCondition()) { case EXCELLENT: conditionFactor new BigDecimal(1.05); break; case GOOD: conditionFactor new BigDecimal(1.0); break; default: conditionFactor new BigDecimal(0.9); break; } // 4. 估价 基准价 * 里程系数 * 车况系数保留两位小数 return basePrice.multiply(mileageFactor) .multiply(conditionFactor) .setScale(2, RoundingMode.HALF_UP); }代码里的几个参数需要调优里程折旧率0.5%和车况系数1.05/1.0/0.9不是凭空定的来源于行业报告的通用折旧模型。你可以把这几项设计成数据库配置表管理员在后台可以调参这样论文里就能写“系统支持估价参数动态配置”也算一个亮点。估价接口的前端展示用ECharts做一个价格区间雷达图或者柱状图把基准价、里程调整后价格、车况调整后价格三个数对比展示页面效果比较丰富。答辩时被问“算法准确性如何保证”你可以准备一组历史数据说明系统会根据每笔新成交自动调整参数权重——如果你的数据量足够甚至可以败一个简单的线性回归模型。这种“能跑通、能讲清、能改进”的小功能是提高项目辨识度的性价比最高路径。给这个系统加的最后一块拼图是你要能亲手演示完整流程。我见过太多学生项目PPT做得花团锦簇答辩现场一打开浏览器Tomcat都没启动。无论如何答辩前一晚把项目从零跑一遍清除数据库测试数据注册一个新账号走一遍“发布车辆-浏览搜索-下单-管理员审核”的完整链路截图存好设备切换的场景都要测过。这是我从考研辅导带项目开始就坚持的习惯——准备得再充分不如现场一次流畅的演示有说服力。希望这篇笔记能帮你少踩几个坑顺利把《雪都出行》这个题目做完交掉。本文还有配套的精品资源点击获取