1. 这个选题到底值不值得做——先替你把关先说结论如果你正愁毕业设计选什么题基于SpringBoot的新能源汽车4S店试驾平台小程序这个方向我能给的评价是——稳妥、有亮点、答辩容易过而且做出来的东西看起来像个“完整产品”而不是一个玩具级管理系统。每年毕业季我都会看到大量倒在选题环节的同学踩的无非是三类坑第一类是题目太大什么“基于深度学习的智慧城市交通系统”听着唬人实际上一学期连数据处理都没做完第二类是题目太水随便一个增删改查的“图书管理系统”就交差了答辩老师问两句就露馅第三类是题目太偏用的技术栈老师不熟、同学不熟、自己更不熟遇到问题连个问的人都没有。这个题目刚好避开了所有坑。它属于“既有业务深度、又有技术支撑点”的中间档选题。所谓业务深度是指它不只是简单的商品展示加下单它包含了试驾预约这种带状态流转、带时间冲突校验、带用户和门店双端交互的业务场景所谓技术支撑点是指SpringBoot加微信小程序这条路非常成熟社区资料多、现成轮子多你遇到问题大概率能搜到答案。另外新能源汽车这几个字也不是白加的。这几年4S店数字化、线上预约试驾是真实存在的行业需求导师一听就知道你不是在空想而是关注了真实的业务场景。答辩的时候你可以很自然地讲出“这个系统解决了用户到店排队、门店排期混乱”这类问题这就叫需求驱动比从技术反推业务的人高明一个段位。还有一点很多人没意识到同一个题目可以做出不同的工作量。如果你只想毕业做到基础版本即可如果你想冲优秀论文可以往车款管理、试驾评价、销售线索转化、数据统计这几个方向去扩展。扩展空间大意味着你后期的主动权在自己手里这是很多死板题目给不了你的。1.1 跟纯管理系统相比试驾平台多了什么很多同学选题目只会在“XX管理系统”里打转比如“宿舍管理系统”“超市进销存系统”。这类系统不是不能做但问题在于它们的核心就是一张表的增删改查业务上几乎没有状态机、没有并发约束、没有多角色权限边界呈现出来的工作量撑不起一篇像样的论文。而试驾平台不一样。以“预约-审核-试驾-完成”这条主线为例一个预约单至少要经历四种状态待确认、已确认、已取消、已完成。每一次状态变更都对应不同的操作权限和校验逻辑。这本身就是很好的论文素材你可以写“基于状态机的试驾预约流程设计”听起来有理论、有实践。再叠加一个时间冲突校验同一辆车在同一时间段不能被两个用户预约。这要求数据库设计时考虑唯一索引或者代码里去查询相交区间。这个问题写进论文里就是一个小的技术亮点答辩时老师大概率会问“你怎么保证同一辆车同一时段只有一个试驾”你能回答上来这就是加分项。微信小程序端则给项目加了“移动端”这个维度。现在的毕设作品纯PC网页的太传统纯App的太费劲小程序正好卡在中间——开发成本不高但展示起来效果很好。演示的时候直接在微信开发者工具里跑起来手机上预览视觉效果比浏览器里刷新Bootstrap页面强太多。1.2 这套东西适合谁做说实话这个选题的受众范围比你想象中宽。如果你是计算机、软件工程这类专业的本科生那它完全符合毕业设计的要求技术栈覆盖了Java、SpringBoot、MySQL外加一点前端小程序开发每一门课都能在项目里找到落点。如果你是那种Java基础一般、没独立做过项目、想通过毕设把自己“练出来”的同学那就更合适了。因为这个项目难度梯度设计得很好最基础的部分你照着文档敲也能跑通稍微进阶的部分比如冲突校验、状态流转做的时候会有点吃力但做通之后你会有那种“原来这些东西是这么配合的”的顿悟感。这种恰到好处的难度比一上来就啃微服务、高并发要友好得多。当然我也要泼一句冷水抱着“只要交了就行”的心态这项目也给不了你什么。源码是别人的文档是现成的老师一问你项目里某个接口的入参是什么、某个表为什么这么设计你如果答不上来反而比做一个简单但自己吃透的项目更危险。所以我把这篇文章定位成“领进门”的东西帮你把这个项目的设计逻辑、技术要点、避坑经验全部捋清楚让你拿到的不仅是一套能交的代码而是真正能讲出来的毕设作品。2. 项目全貌技术栈与核心功能拆解在写代码之前先在脑子里把这个项目的整体架构画出来这是做毕设最重要的一步。很多同学拿到项目就急着跑起来、急着改功能结果跑通之后脑子还是一团浆糊答辩时连“系统的模块划分”都讲不清楚。我建议大家反过来先把架构图、功能清单、数据表关系吃透再去看代码。这个项目整体上是前后端分离的结构。后端用SpringBoot提供RESTful API前端分为两个部分用户端是微信小程序管理端可以是另一个小程序页面也可以是Web管理界面。数据统一存储在MySQL中。用户通过微信小程序浏览车辆、查询门店、提交试驾预约管理员在管理端维护车辆信息、处理预约、管理门店两端通过后端接口交互接口返回JSON数据。2.1 前后端分离与微信小程序这套技术栈为什么稳选技术栈这件事核心原则是“主流、够用、你能解释”。后端的SpringBoot不用多解释现在Java方向的毕设十有八九是它。它的好处是自动化配置、内嵌服务器、生态成熟写接口非常快而且网上现成资料多到泛滥。搭配的持久层框架建议选MyBatis-Plus因为它的条件构造器写起来非常方便一个Wrapper就能搞定复杂查询对新手极其友好也省掉大量配置XML的时间。前端为什么选微信小程序而不是普通网页除了“移动端展示效果好”之外还有一个更现实的原因微信登录体系是现成的。如果做普通Web项目你得实现一套完整的用户注册、登录、会话管理工作量至少多出一个模块。而小程序端通过wx.login获取code后端调微信的接口换openid一套下来不到五十行代码用户身份就搞定了。省下来的时间可以做更有价值的业务逻辑。再说管理端。有的同学会问管理端也用小程序吗我的建议是如果项目只要求两个端用户小程序 后台管理那管理端直接用Vue加Element UI做一个单页应用最快如果你不想碰Vue也可以把管理端做成小程序的后台页面甚至用最原始的方式——在后端项目里加几张Thymeleaf模板页面。具体选择看你的时间安排和技术储备不影响主项目的评价。MySQL不用多说单机部署、免费、教程多。这个项目的数据量不会很大根本不需要上Redis和消息队列把MySQL表设计得合理一些就足够支撑整个系统的业务了。答辩时老师如果问“为什么不用Redis缓存”你可以回答“当前阶段MySQL索引优化已满足需求Redis留作后续扩展点”这话既诚实又显得你有规划。2.2 用户端从浏览车辆到确认试驾的完整链路用户端的功能可以梳理成一条主线注册登录 → 浏览车款 → 查看门店 → 提交试驾预约 → 查看预约状态 → 到店试驾。这条链路环环相扣每一步都对应着后端的一组接口和数据库的一张表。第一步是微信授权登录。用户在小程序里点击“微信一键登录”前端拿到code后发给后端后端调用微信接口获得openid用openid去用户表里查有没有这个用户没有就自动注册一个然后返回一个token给前端。后续所有请求都带着这个token后端通过拦截器验证用户身份。登录之后是车辆浏览。首页可以按品牌、车型、续航进行分类展示每个车辆卡片上展示车名、续航里程、参考价格、外观图片。点击详情页可以看到更完整的信息——车身尺寸、电池容量、驱动方式、加速时间、车辆特色描述。这些内容都来自article_vehicle表展示也是直接读库。用户选中一辆感兴趣的车之后下一步是选门店试驾。门店列表从store表读取展示门店名称、地址、营业时间和联系电话。有些系统还会在车辆详情页标出“可试驾门店”也就是这辆车库存里实际存在的门店这需要车辆和门店做一个关联查询。接下来的预约流程就是这套系统里最有含金量的部分我会在第4章重点拆解。预约提交后用户在小程序端能看到自己的预约列表列表里展示预约单号、车辆、门店、预约时间段、当前状态。状态变化也会实时刷新比如管理员确认后状态从“待确认”变成“已确认”用户取消后变成“已取消”。这个“状态可见性”很重要它让用户感觉到系统是活的而不是填完表单就石沉大海。2.3 管理端车辆、门店、预约这三块怎么管管理端围绕经营者的视角设计核心任务是让管理员能高效地维护主数据和审核预约订单。功能上至少包含三个模块车辆管理、门店管理、预约审核管理如果还想再丰富一点可以加一个用户管理和数据统计。车辆管理模块解决的是“车从哪里来”。管理员需要有新增车款、编辑车辆信息、上传车辆图片、上下架车辆这几个操作。上架之后用户端才能看到这辆车下架之后客户端隐藏。这个上下架状态的逻辑虽然简单但在论文里可以写成“基于状态字段的车辆展示控制”也算是个小设计点。门店管理模块相对简单就是维护门店的基本信息店名、地址、电话、营业时间。但这个模块的价值在于它为试驾预约提供了“场地”维度。没有门店预约就无处落地。预约审核模块是整个管理端的重点。管理员打开预约列表看到的是所有用户的试驾申请每条申请包含用户信息、车辆信息、门店、预约时间段和状态。管理员可以点击“确认”表示这个时间段可以试驾也可以点击“取消”并填写取消原因。这里要注意取消操作一定要写原因因为用户端要展示这个原因不然用户体验会非常差。如果时间充裕还可以加一个统计看板当天预约数、各门店预约量、热门车型Top5。这些数据用MyBatis-Plus的聚合查询就能做出来但放在答辩展示里非常提气因为老师一看就知道你做了“数据分析”层面的工作。哪怕只是几个柱状图也比你纯表格列表要有说服力。3. 数据库设计这几张表才是项目的命根子很多同学做毕设有个坏习惯——急着写代码表结构随便建字段缺胳膊少腿做到一半发现要加字段改动牵连一大片。我做了这么多年项目最深的一个体会是数据库表设计得好后面写接口就是填空表设计得烂写一行SQL都难受。所以我强烈建议你第一次通读项目时先把所有建表语句看一遍并且在纸上把表和表的关系画出来。这个项目的核心表大概有六七张我挑关键的几张给你逐字段拆解。3.1 车辆表与门店表基础数据怎么建模车辆表car_info是展示模块的数据源头。常见的字段有id、品牌brand、车系series、车型名model_name、指导价guide_price、续航里程battery_range、车身尺寸body_size、电池容量battery_capacity、电机类型motor_type、百公里加速acceleration、车辆描述description、主图main_image、轮播图slider_images、状态status。有一个地方特别容易踩坑价格和续航里程这类数值字段建议用DECIMAL和INT不要用VARCHAR。原因很简单如果存的是字符串“450km”你要做按续航排序的时候就傻眼了必须得转类型索引还失效。数字就存数字单位的展示留在前端处理。这就是典型的“库表设计时的类型洁癖”现在讲究一点后面省很多事。门店表store_info的字段就朴素得多id、门店名称、门店地址、联系电话、营业开始时间、营业结束时间、门店经度、门店纬度、状态。经纬度字段如果你后面想做“附近门店”功能就用得上用高德地图API能显示门店位置。如果不想做地图功能这两个字段可以留着不用但不建议删因为作为扩展点留在文档里也是加分项。车辆和门店是多对多关系。一辆车可能在多个门店有试驾车一个门店也有多辆试驾车。所以得建一张关联表car_store_rel字段就是car_id和store_id再加个库存数量stock。有了这张表用户端“车辆详情页显示可试驾门店”的需求就出来了查询是两个表内连接非常清晰。3.2 试驾预约表状态机是整套系统的灵魂试驾预约表是项目里最值得花心思设计的表名字可以叫test_drive_appointment也有人叫appointment_order。这张表的字段设计直接决定了你的核心业务能跑多远。我先列一下关键字段id、预约单号appointment_no、用户iduser_id、车辆idcar_id、门店idstore_id、试驾日期test_drive_date、开始时间start_time、结束时间end_time、状态status、取消原因cancel_reason、创建时间create_time、更新时间update_time。预约单号这是很多人容易忽略的字段。它是用户看到的业务标识一般用时间戳加随机数生成比如“TD202501011300001234”。这个单号要唯一方便用户咨询时客服查单也方便日志追踪。虽然主键id也能标识一条记录但用户不会去记一个自增id单号这个字段更符合业务直觉。**状态status**是整个预约流程的核心。我建议用TINYINT存数字枚举0代表待确认、1代表已确认、2代表已取消、3代表已完成。注意不推荐用VARCHAR存“待确认”“已确认”这种中文一是占空间二是容易拼写不一致三是业务要加新状态时要改数据。代码里建一个枚举类去映射即可这也是论文里可以写“基于状态模式的预约流程管理”的依据。还需要考虑一个点试驾时长。很多初版设计只存一个开始时间结果管理员确认的时候没法判断这辆车这个时间段能不能安排。建议存start_time和end_time这两个字段后端统一默认每个试驾时间段为30分钟或1个小时这样冲突校验就很容易写。另一个值得提的字段是试驾体验反馈。如果系统支持用户试驾完成后填写评价比如“车辆操控感受”“销售服务态度”这几个字段那就变成了一个有“试驾评价”模块的项目又比普通预约系统多了一层。评价可以和订单表关联做成一对一的扩展表test_drive_feedback。这不难做但确实能写出“预约试驾闭环管理”的论文章节。3.3 用户表与关联表的字段设计细节用户表用的是标准微信小程序用户结构id、openid唯一标识、昵称nickname、手机号phone、头像avatar_url、注册时间create_time、最近登录时间last_login_time。这里有个细节openid是微信生态里每个用户的唯一凭证你的登录逻辑全靠它所以必须加唯一索引。手机号这个问题要单独说一下。微信小程序拿用户手机号有两种方式一种是引导用户填写表单另一种是通过微信的getPhoneNumber能力在用户授权后直接解密获得。毕设阶段用表单填写的方案就足够了不要为了炫技去碰解密那块非对称解密处理起来很麻烦而且容易因为配置问题翻车。除了上面这几张主表还有一张表值得提前设计系统操作日志表。它可以记录谁在什么时间做了什么操作比如“管理员确认了预约单TD202501011300001234”。这个功能普通毕设不做也行但如果你的论文题目里写了“管理”二字加一张日志表会显得系统在安全性和可追溯性上有思考而且实现成本很低一个切面或一个拦截器就搞定了。最后再强调一下所有表都要有的两个字段create_time和update_time。这是MyBatis-Plus自带的自动填充字段设置一下填充策略插入和更新时自动维护不用人工写时间。数据库里也别忘了给这两个字段加默认值CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP双保险。4. 核心功能实现试驾预约从提交到完成全流程数据库设计好了现在进入“代码到底怎么落”的阶段。试驾预约流程是这个项目的核心链路我带着你走一遍从后端接口定义到小程序端交互的完整实现顺便把最容易翻车的几个点给你标出来。4.1 后端接口设计预约、确认、取消怎么分工一套清晰的接口设计能让你少写一半的重复代码。我按功能模块把接口列一下你对照着手头的代码就能快速定位。用户相关的核心接口POST /api/user/login微信登录、GET /api/user/info获取用户信息、PUT /api/user/info修改用户信息。车辆相关的核心接口GET /api/car/list分页条件查询车辆列表、GET /api/car/detail/{id}车辆详情、GET /api/car/store/{id}车辆可试驾门店。预约相关的核心接口POST /api/appointment/submit提交预约、GET /api/appointment/list我的预约列表、GET /api/appointment/detail/{id}预约详情、PUT /api/appointment/cancel取消预约。管理相关的核心接口POST /api/admin/vehicle/save新增或编辑车辆、DELETE /api/admin/vehicle/{id}删除车辆、GET /api/admin/appointment/list所有预约列表可按状态筛选、PUT /api/admin/appointment/confirm确认预约、PUT /api/admin/appointment/cancel管理端取消预约。在这些接口里POST /api/appointment/submit 是最复杂的。它要做的事很多拿到用户token解析出用户id校验车辆、门店是否存在且状态正常校验预约日期和时间段是否在门店营业范围内校验这个车辆在这个门店的这个时间段是否已经被预约如果校验通过插入一条预约记录状态设为待确认然后返回预约单号。这里有一个实用性很强的建议校验业务规则不要写在Controller里要写到Service层最好抽一个独立的校验方法。因为提交和确认这两个操作都会用到冲突校验抽出来复用后面改逻辑只改一处这是“高内聚低耦合”在这个项目里最实在的落地。你可以在论文里写“将业务校验下沉到Service层以提升复用性”老师听了会点头。4.2 时间冲突校验同一辆车同一时段不能有两个试驾这是整个项目技术含量最高的点之一也是答辩老师最感兴趣的点。面试和答辩的时候被问“你这系统怎么防止两个人同时约同一辆车”的概率非常高所以这一节你要看得格外仔细。先说思路提交预约时已知条件是车辆id、门店id、试驾日期、开始时间、结束时间。要判断冲突就是查一下这张表里有没有一条记录满足同样的车辆、同样的门店、同样的日期并且状态不是已取消而且时间段有重叠。重叠的判断条件是新预约的开始时间小于已有预约的结束时间并且新预约的结束时间大于已有预约的开始时间。这是时间区间重叠的标准判断逻辑用SQL表达就是SELECT COUNT(*) FROM test_drive_appointment WHERE car_id #{carId} AND store_id #{storeId} AND test_drive_date #{date} AND status ! 2 AND start_time #{endTime} AND end_time #{startTime}如果查出来的count大于0就说明这个时间段已经被占了直接抛业务异常提示用户“该时段已被预约请选择其他时间”。但光有查询还不够还有一个高并发下的隐患两个用户同时提交同一个时间段的预约两个请求都查到count为0然后同时插入结果就两条记录同时存在。这类问题叫“竞态条件”在真实的面试和答辩里是被问滥了点。解决它有两条思路任选其一即可。第一是用数据库唯一索引“硬控”在预约表上建一个联合唯一索引索引包含car_id、store_id、test_drive_date、start_time。这样数据库层面就杜绝了同一辆车同一时刻的重复记录插入时如果撞了唯一索引代码里捕获DuplicateKeyException再转成友好的提示即可。第二种方法是用synchronized或者分布式锁但分布式锁在这个项目里属于过度设计毕设阶段完全没必要。我建议你采用唯一索引方案因为它的逻辑简洁、大学里讲数据库时也提过组合索引你答辩解释起来毫不费力。加上这个索引之后冲突校验就变成两道防线业务查询拦截绝大多数冲突数据库索引兜底极端并发。你能讲出这层“双层防护”的逻辑问题的回答分数不会低。4.3 小程序端页面逻辑从选车到提交预约的交互细节小程序端的页面结构是典型的“底部导航加四个Tab”布局首页展示车辆推荐和公告、车款页展示车辆列表、试驾页展示我的预约、我的页面展示个人中心。这四个Tab撑起了用户端的主框架。提交预约的交互流程是这样的用户在车辆详情页点击“预约试驾”跳转到预约页面页面顶部展示车辆的基本信息和缩略图中间是门店选择点击门店可以选择试驾地点下面是一个日期选择器和一个时间选择器用户选择日期和时段后页面底部实时显示“预约X月X日X点到X点试驾”最后点提交。这里有一个交互上的细节非常影响用户体验时间选择器要拿到后端返回的“可用时间段列表”而不是让用户随便选。较好的做法是后端在返回车辆详情或门店详情时顺带把门店营业时间内已经被约满的时间段查出来小程序端把已满的时间置灰用户只能选有空位的时段。这个功能的实现不复杂后端无非是查一下预约表按时间段聚合计数但做出来之后整个系统的“专业感”立刻不同。答辩的时候你可以说“我从交互层面做了预约冲突的预防而非仅在提交时提示失败”这个设计理念站在了用户体验的角度上导师会觉得你有产品思维。预约列表页同样有交互要求。列表里要展示状态标签颜色按状态区分待确认是黄色、已确认是绿色、已取消是灰色、已完成是蓝色。点击一条预约记录可以进详情页看到完整的预约信息和状态流转记录。试驾完成后用户可以在详情页填写评价这些数据写入test_drive_feedback表。小程序端的请求封装也要注意统一用Promise风格封装wx.request公共请求header里带上token。后端用拦截器Interceptor校验token拦截除了登录接口之外的所有接口。这个“统一鉴权”能力虽然简单但它是系统自我保护的基本底线也是答辩时能讲清楚的又一个功能点。5. 踩坑记录与排查技巧——这些坑我先替你踩一遍做项目最怕的不是不会做而是遇到了问题不知道从哪查。这一章我把我实际开发中反复踩过的、以及带毕设学生时常见的一堆问题整理出来按排查思路的方式讲。这些问题不一定你全都会遇到但遇到任何一个你都能照方抓药。5.1 微信登录的session_key与openid处理微信登录这套逻辑是做小程序项目绕不过去的坎也是报错高发区。常见的坑有两个。第一个坑是code只能用一次。wx.login每次登录都会生成一个新的code但这个code只能用一次而且有效期只有五分钟。如果你调试的时候在一个页面里调了两次wx.login或者后端解密session_key时报错再回头把旧的code重发一遍就会得到“40029 code无效”的报错。解决办法是登录接口只调一次wx.login拿code去换openid和session_key后续的用户信息查改用token不要再重复换。第二个坑是session_key不等于登录态。有的同学会拿session_key当token直接返回给前端这不对。session_key是微信用来解密数据的密钥它和你的系统登录态没有直接关系。正确做法是用openid查库找到用户id然后自己生成一个token可以用JWT也可以用UUID把这个自定义token返回给前端后续请求都带这个自己的token。把session_key只用在需要解密用户手机号或敏感数据的时候不要混用。如果你用的是某个现成的小程序登录鉴权框架比如Sa-Token配合Sa-Token-OAuth2模块或者自己手写拦截器加ThreadLocal存储用户信息大方向是一样的微信只负责证明你是你剩下的会话管理交给自己。这个概念讲清楚答辩时关于登录环节的提问基本都能应付。5.2 预约状态流转与“幽灵预约单”很多刚做完预约功能的人会遇到一个奇怪的问题用户提交预约成功了管理端也能看到记录但是用户端点“取消预约”之后管理端待确认列表里还显示着这条。找半天原因发现是更新状态时按主键id去更新但前端传错了参数把appointment_no当id传了。这种问题属于“业务参数混淆”排查时首先确认前端传参是否和后端接口定义一致。还有另一个更隐蔽的坑状态更新没有加user_id条件。比如用户A取消预约时请求里带了预约单id后端update语句只按id更新了status但没校验这个预约单是不是属于用户A。结果就是用户B拿着A的预约单id也能调用取消接口直接把A的预约取消了。这是典型的越权操作虽然毕设项目没人真去攻击它但答辩老师特别爱问“你怎么防止用户B操作A的数据”你如果在Service里加了“预约单归属校验”就能稳稳接住这一问。具体写法很简单取消接口先查预约单判断记录的user_id是否等于当前登录用户id不一致直接抛“无权操作”。如果你用了MyBatis-Plus可以写成update时用eq(id, id).eq(user_id, userId)来拼条件数据库层面锁死归属关系。这行代码不复杂但它是安全性和逻辑严密性的体现。再有一个“幽灵预约单”的坑用户提交预约后没付款如果项目里设计了预约押金也没取消这条预约就会一直占着时间槽位导致其他用户永远选不了这个时段。真实业务里常用“超时自动取消”解决预约创建时记create_time用定时任务扫描超过30分钟仍为待确认的记录自动改成已取消。SpringBoot里加一个Scheduled注解就能搞定。这个功能加进去之后你的系统就有了一个自动化后台任务又是一个可以在论文里单独讲一节的点。5.3 小程序真机调试与本地联调的常见问题小程序开发和PC开发有一个明显的差异它有一个“微信开发者工具”让你在电脑上写代码可以即时预览效果。但真机预览是另一套逻辑常见的问题通常集中在网络和域名上。如果你用本地SpringBoot接口联调微信开发者工具默认环境下需要在“详情-本地设置”里勾选“不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书”。不勾选的话请求会被block掉报“request:fail url not in domain list”。这个问题新手几乎必踩提醒一次你就记住了。到了真机调试问题就变了。手机上的微信小程序默认只允许请求HTTPS的合法域名而你的本地后端是HTTP的怎么办两个解决方案一是用内网穿透工具把你的本地端口映射到公网HTTPS地址开发者工具里临时校验域名之后在真机上调试二是部署到云服务器用Nginx配一个HTTPS证书后端和前端都上线。毕设项目如果只要演示方案一就够用了如果要给导师远程演示那就得走上线的路。另外一个常见的联调问题出现在“跨域”上。老生常谈前后端分离项目必须处理跨域但这里要注意微信小程序的请求其实不受浏览器同源策略限制理论上不跨域。但如果你管理端是Vue网页那就绕不开跨域配置。后端统一加一个CorsConfig允许对应域名的跨域请求。另外前后端本地联调时面临的端口不一致问题管理端一般配一个Vite代理或者Nginx转发把 /api 前缀的请求转发到后端端口。5.4 答辩前需要准备的几样东西如果你用的是带有完整文档和源码的毕设资源我提醒你代码本身不算交付物你能讲清楚才算数。答辩的前一个礼拜除了改Bug你必须准备下面几样东西。第一画好系统架构图和功能模块图。不需要多精美PowerPoint画出来的也可以但结构要清晰用户端、管理端、后端、数据库四个层次标注好核心功能点。答辩开场先讲架构图老师对你的第一印象就是“这个学生做过事”。第二准备一套完整的演示数据。车辆、门店、预约单都要有几条看得过去的记录预约单最好覆盖“待确认、已确认、已完成、已取消”四种状态这样演示时可以很自然地展示每一条流程。不要用“哈哈”“测试”这种命名会让整个系统看起来非常随意。第三准备几个“预期问题”的答案。例如“重复预约怎么处理”“openid是什么”“为什么用MyBatis-Plus不用JPA”“状态字段为什么用数字不用中文”这类问题我前面都讲过了你把自己项目的对应答案想好到时候对答如流基本就稳了。第四把项目的启动步骤写成一个简洁的README。这既是给自己的备忘也方便导师或评审老师自己去跑。一个能跑起来的项目和一个跑不起来的项目获得感差距是巨大的。6. 关于源码、文档和调试我说几句实在话市面上关于这个题目的资源确实不少挂着“附源码、MySQL、文档、调试加代码讲解全包”这类字眼的也很多。作为一个帮你把关的人我有几句实在话必须说在前面。第一源码一定要自己跑通并且亲手改过几处。只下载、只运行、不修改这不叫掌握项目。我的建议是拿到项目后做三件事一是把数据库连接改成你自己的MySQL账号密码二是把车辆表里的几条数据改成新能源汽车的常见车型比如某国产品牌的热门纯电车型让数据看起来符合项目定位三是找一个你觉得UI不够好看的小程序页面改一版样式。这三件小事做完项目至少有一半像是“你的”了。第二文档不要直接复制粘贴提交。很多现成文档的质量参差不齐有些甚至数据库字段和代码都对不上。你一定要把文档从头到尾读一遍发现不一致的地方就改哪怕只是字段名写错也比答辩时被老师抓包好。这也是为什么“懂代码”比“有代码”重要。第三妥善规划时间。毕设延期这件事几乎每年都有原因往往不是题目难而是前期拖太久。拿这个项目来说我建议你按三周来排第一周跑通环境从头到尾走一遍用户端和管理端流程第二周读懂核心代码把表结构、接口列表、状态流转口述清楚第三周做个性化改动准备答辩材料。这个节奏不算赶但也不会让你拖到最后一个月才慌。说到底毕设的意义不在于题目多高级、代码量多大而在于你有没有真正掌握一个系统的构建方法。新能源4S店试驾平台这个题目给了你一个绝佳的练兵场技术栈主流、业务清晰、扩展空间充足。你把它吃透了不只是过一关答辩的事而是你会发现SpringBoot那一套东西以后再见到心里有底了。我自己的感受是每一次带这种预约类项目的初学者最让我欣慰的时刻不是项目跑通的那一刻而是对方在踩完坑之后自己说出“哦原来这个报错是这个意思”的时候。这个项目里藏着不少这样的顿悟点你踩实了它们毕业设计就不只是一项任务而是你真的往工程师的方向又近了一步。最后再分享一个小技巧答辩前找几个同学让他们以老师的口吻轮流“盘问”你一遍项目问得越狠越好。你可能会被问到开不了口的地方但正是那些问题帮你把最后的漏洞补上了。这个办法我在每一次项目答辩前都用从不落空。