每年三四月份就会有一批同学开始为毕业设计焦虑。如果你正好刷到这个题目说明大概率也处在选题阶段。我当年做的项目就是SSMVue的临时停车收费系统从选题立项、开发调试一直到论文查重、答辩通过整个过程踩坑不少但回头来看收获也很大。这个题目看上去普通却是毕设里最稳的一类——技术栈经典、需求清晰、场景贴近生活老师能提问的方向基本有数不太容易翻车。这篇内容我把整个项目从需求分析、数据库设计、后端接口、前端页面到论文结构全流程拆给你看尤其是那些翻了很久资料才找到答案的坑我会尽量写清楚。1. 项目整体设计与需求拆解1.1 为什么推荐SSMVue这个组合先聊一个很多人纠结的问题现在外面企业都在用SpringBoot为什么毕业设计还要选SSM我的看法是毕设和公司项目是两回事。毕设的评分标准里很重要的一条是“你对框架原理的理解程度”。SSM作为经典的前后端分离项目框架组合能逼着你把Spring的IOC和AOP、SpringMVC的请求流转、MyBatis的SQL映射独立配一遍。这个过程虽然繁琐但你会发现当你亲手把web.xml、spring-mvc.xml、mybatis-config.xml这些配置搭建起来你对整个Java Web开发的底层认知会有一个质的提升。反观SpringBoot很多东西自动配置了反而少了一层理解。从答辩角度讲SSM也更好讲。老师问“SpringMVC的执行流程是什么”“MyBatis的#{}和${}有什么区别”这些网上有大量经典答案你能答得头头是道。Vue则负责前端表现跟后端完全解耦正好体现“前后端分离”这个设计思想。整体技术栈难度中等工作量可控对大多数同学来说既能完成又有内容可写。1.2 临时停车收费到底要解决哪些问题这个系统的场景很直白商场、医院、小区周边这类停车场的临时车辆进来的时候登记车牌、分配车位走的时候按停车时长计算费用并结算。之所以比固定车位管理系统更有代表性是因为它涉及一个核心难点——动态计费。把你的系统当作一个停车场收费员来思考日常要做的事无非几件车辆进来给个位置、记下时间车辆出去抬起头看停了多久、该收多少钱然后放行。放到系统里对应的就是车位管理、入场登记、出场结算、流水记录、统计报表。再往深处想还要处理“车位满了怎么办”“计费规则怎么配置”“跨天停车怎么算钱”这些业务细节。我建议在正式开始写代码之前先把这些问题画成用例图。不需要画得多规范重点是让脑子里的流程闭环。画完之后你会发现其实核心流程就两条一条是车辆入场到出场的状态流转另一条是管理员对系统的数据维护。想清楚了再动手效率会高很多。1.3 角色划分与业务流程这个系统我设计的是单角色即停车场管理员。很多同学觉得角色越丰富越好于是硬加一个“用户端”让车主也能登录查看缴费记录。我个人的建议是毕设追求的是“需求完整、逻辑闭环”角色和功能要配得起来宁缺毋滥。加一个车主端意味着要处理注册、登录、个人信息、订单查询一堆东西工作量翻倍不说答辩时还容易被追问“车主登录的意义是什么”。如果你是冲着优秀毕设去的另说如果求稳先以管理端为主把业务流程跑通。管理员角色的核心业务可以整理成五条线登录认证、车位状态管理、入场登记、出场计费、记录统计。车辆入场时管理员录入车牌号系统自动分配空闲车位并写入入场时间车辆出场时管理员根据车牌或记录编号调出入场信息系统按规则计算费用确认收款后释放车位。整个流程可以用一句话概括记录车辆在场内的停留时段并在离开时把时段换算成金额。2. 数据库设计与收费规则建模2.1 四张表撑起整个系统数据库设计是毕设答辩必问的环节也是后期改代码最伤筋动骨的一环前期一定要多花时间。我们这个项目的核心表就四张管理员表、车位表、收费规则表、停车记录表。先看最核心的停车记录表它记录的是每一辆车从入场到出场的完整生命周期字段名类型说明idbigint主键自增plate_numbervarchar(20)车牌号入场时录入space_idbigint占用的车位ID关联车位表entry_timedatetime入场时间exit_timedatetime出场时间为空表示仍在停放total_feedecimal(10,2)实收金额用decimal避免浮点误差statustinyint0在停、1已离场create_timedatetime记录创建时间收费规则表我单独拆出来这是整个系统里最值得讲的表。把计费参数配置化而不是写死在代码里是体现你系统设计能力的关键点。字段包括规则名称、免费时长分钟、首小时费用、超出后每小时费用、单日封顶金额、生效时间。这样做的好处是以后调价格只改数据库不用改代码重新部署。车位表、管理员表相对简单重点提醒一下车位表里status字段用0空闲、1占用跟停车记录表的status含义不同不要搞混。另外我的车位表里加了一个location字段用来标记车位位置比如“A区01号”前端展示的时候会更直观。2.2 收费规则怎么设计才合理收费规则是整个系统业务的灵魂也是论文里能写、答辩里能讲的重头戏。我采用的规则是入场15分钟内免费超过免费时长后首小时收费5元不满1小时按1小时计超出首小时后按每小时2元累加单日封顶30元。用一个具体例子走一遍车辆14:20入场18:50出场。停车总时长4小时30分钟。先减掉免费时长剩余4小时15分钟。首小时5元剩下3小时15分钟按4小时计每小时2元即8元。总费用13元。注意这里“超出首小时后”的3小时15分钟在计费时按超过的整小时数向上取整因为在停车场景里是“停满一个计费单位就产生相应的费用”。跨天计费是这个系统的加分项。很多同学的规则是简单按总时长算然后被封顶逻辑限制住了。我的做法是先判断入场时间和出场时间是否在同一天如果跨天则把停车时段按自然日切割每一天单独按规则计算再累加。比如20日22:00入场21日9:00出场20日算2小时首段费用21日算9小时费用各自遵守当天封顶最后相加。这个逻辑写进论文里老师会觉得你考虑得周全。2.3 数据一致性与查询性能细节数据库层面的细节我吃过不少亏帮大家提前避一避。第一金额字段用decimal(10,2)不要用float或double。float在计算时会出现类似0.10.20.30000000000000004的问题停车费涉及钱这种误差不能忍而且答辩时老师问到精度问题你答不上来会很尴尬。第二停车记录的status字段和exit_time字段要有意配合使用。出场时间为空且status为0表示车辆在场内出场时间非空且status为1表示已结算。这两者必须保持一致我在出场结算的service方法里加了事务控制确保更新记录、释放车位两个操作要么同时成功要么同时回滚。第三车牌号、入场时间这两个字段要加索引。别看毕设数据量小感觉不出来但论文里写到“对高频查询字段建立索引以提升检索效率”这句话是有含金量的说明你考虑了实际生产环境。3. 后端SSM实现从框架配置到核心业务3.1 项目分层与工程搭建后端我按标准的SSM结构来组织包采用了controller、service、mapper、entity、config五层结构具体目录如下parking-system ├── controller │ ├── AdminController.java │ ├── CarController.java │ ├── RecordController.java │ └── StatisticsController.java ├── service │ ├── ChargeService.java │ ├── ParkingRecordService.java │ └── ... ├── mapper │ ├── AdminMapper.java │ ├── ParkingRecordMapper.java │ └── ... ├── entity │ ├── Admin.java │ ├── ParkingRecord.java │ ├── ParkingSpace.java │ └── ChargeRule.java └── config └── ...搭建工程时有几个配置细节容易卡住新手。一是SpringMVC的注解扫描要覆盖controller包Spring的注解扫描要覆盖service包两者不要混在一起二是MyBatis的mapper接口和mapper XML文件在target目录里可能不会一起打包如果启动后报“Invalid bound statement”多半是pom.xml里少了resource配置三是数据库连接参数里的serverTimezone一定要加上不然时间显示会差8个小时。工程搭建这一步我建议对照网上任何一个SSM整合教程走一遍跑通一个最简的Hello接口之后再开始写业务。不要一上来就同时写一堆代码否则报错的时候你根本分不清是配置问题还是业务逻辑问题。3.2 入场与出场结算的实现逻辑入场登记的逻辑看起来简单但顺序很重要。我写的入场代码如下public Result entry(String plateNumber) { ParkingSpace space spaceMapper.findFreeSpace(); if (space null) { return Result.error(当前车位已满); } ParkingRecord record new ParkingRecord(); record.setPlateNumber(plateNumber); record.setSpaceId(space.getId()); record.setEntryTime(new Date()); record.setStatus(0); recordMapper.insert(record); spaceMapper.updateStatus(space.getId(), 1); return Result.success(record); }这段代码有三个要注意的地方。第一必须先查空闲车位再插入记录如果车位满了就直接返回提示不要继续执行。第二插入停车记录和更新车位状态这两步必须放在同一个事务里否则可能出现“车进来了但车位状态没变”或者“车位显示占用但记录丢失”的问题。第三车牌号在Controller层要做统一的格式处理转成大写并去掉空格免得同一个车被录入成“京A12345”和“京a12345”两条记录。出场结算的逻辑相对复杂核心是先算时长再算钱然后把状态改为已离场并释放车位Transactional public Result exit(Long recordId) { ParkingRecord record recordMapper.findById(recordId); if (record null || record.getStatus() 1) { return Result.error(记录不存在或已结算); } record.setExitTime(new Date()); BigDecimal fee chargeService.calculate(record.getEntryTime(), record.getExitTime()); record.setTotalFee(fee); record.setStatus(1); recordMapper.update(record); spaceMapper.updateStatus(record.getSpaceId(), 0); return Result.success(fee); }结算时还有一个边界情况要处理如果管理员误操作把同一辆车结算两次第二次进来时必须给出“已结算”的提示不能重复收费。这就是我在方法开头判断status的原因也是答辩时能主动讲出来的细节。3.3 金额计算与并发安全收费计算的核心代码我单独抽了一个ChargeService方便复用也方便单独测试。具体逻辑是先计算总分钟数再按规则表里的配置逐级计算public BigDecimal calculate(Date entryTime, Date exitTime) { long minutes Duration.between( entryTime.toInstant(), exitTime.toInstant()).toMinutes(); ChargeRule rule ruleMapper.getLatest(); if (minutes rule.getFreeMinutes()) { return BigDecimal.ZERO; } long billableMinutes minutes - rule.getFreeMinutes(); BigDecimal fee rule.getFirstHourFee(); long extraHours (billableMinutes - 60) / 60 1; fee fee.add(rule.getHourlyFee().multiply( BigDecimal.valueOf(extraHours))); if (fee.compareTo(rule.getDailyCap()) 0) { fee rule.getDailyCap(); } return fee; }我特意用Duration.between来计算时长而不是手动用毫秒数相减再除以3600000因为后者在跨天、跨月、夏令时等场景下容易出问题读代码的人也不容易一下看懂。金额计算全部走BigDecimal不能直接对BigDecimal调用multiply之后忘记接收返回值BigDecimal是不可变对象每次运算都会产生新对象这一点我在代码里吃过一次亏写出来提醒大家。并发安全方面毕设阶段不需要上特别复杂的锁机制但至少要理解问题存在的场景。比如两个管理员同时操作同一个车位或者同一辆车同时被两个窗口结算解决思路是用数据库的事务加上状态字段的乐观判断更新时带上WHERE status 0如果影响行数为0说明记录已经被处理过。这个简单策略在论文里写清楚老师会觉得你有工程意识。4. Vue前端从零搭建到上线运行4.1 环境准备与前端选型前端我选择Vue 3 Vite Element Plus Axios ECharts这个组合。如果学校要求Vue 2那对应的组件库就是Element UI原理完全一样后面讲到的思路照样适用。这里的核心原则是前端框架选你用得顺手的组件库选和框架版本匹配的别混搭。Vue 2配Element Plus会直接报错Vue 3配Element UI也一样跑不起来。环境准备这几个环节最容易卡住新手先装Node.js然后用npm install -g vue/cli或者用npm create vitelatest创建项目接着npm install安装依赖最后npm run dev启动开发服务器。整个过程中如果遇到npm install卡住建议换成镜像源速度会快一个量级。另外启动成功后Vite默认端口是5173后端Tomcat默认8080两边端口不同这就涉及后面的跨域配置。组件库安装之后记得在main.js里做全局注册这样所有页面都能直接使用Element Plus的组件。这个步骤很简单但我在给不少同学看代码时发现他们忘了这一步导致页面上所有组件的样式全部失效报错信息又不明显排查起来特别费劲。4.2 页面功能拆分与组件实现前端页面我按功能模块拆成了五个视图登录页、车位总览页、入场登记页、出场结算页、停车记录页外加一个统计报表页。每个页面尽量独立成一个文件夹组件内部再拆子组件能明显降低后面对照后端改接口时的心智负担。车位总览页是最能提升系统视觉效果的功能。我用的方案是Grid网格布局每个车位一个卡片空闲状态显示绿色、占用状态显示红色卡片上直接展示车位号和当前车牌号。这个页面不仅演示效果好开发也不复杂就是用v-for遍历车位列表然后根据status字段动态绑定样式类名。答辩演示时你先打开总览页然后去执行一次入场操作回来刷新页面车位从绿变红这就是一个完整的、看得见摸得着的业务流程演示。入场登记页和出场结算页在操作上有天然的先后关系我把它们放在同一个父组件里管理。入场时弹出一个对话框输入车牌号后调接口出场时也弹对话框输入车牌或选择一条在停记录页面会实时显示应收金额。这里有个交互设计经验确认出场按钮点击后要等后端返回成功再把对话框关掉不要在点击的瞬间就关闭否则接口失败时用户完全无感知会以为已经结算成功了。4.3 跨域联调与生产部署前后端分离开发时最折磨人的就是跨域。开发阶段我推荐用Vite的proxy代理在vite.config.js里配置export default { server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这样前端代码里请求/api/car/entryVite会自动把请求转发到后端的8080端口浏览器层面不存在跨域问题。这个方案比在后端写CORS过滤器更省心不需要改Java代码缺点是只有开发环境生效。到了部署阶段我采用的是生产中很常见的方式把Vue项目打包后放进SpringBoot项目中运行。执行npm run build之后dist目录下就是打包好的静态资源把这些文件复制到后端项目的src/main/resources/static目录下启动Tomcat访问http://localhost:8080就能直接打开整个系统。这样做的好处是最终只需要部署一个Java服务不用额外配置Nginx部署简单答辩演示也方便。但这里有一个很隐蔽的坑如果前端路由用的history模式直接刷新页面会出现404因为后端没有配置对应的路由转发。解决方式有两种一是前端路由改用createWebHashHistoryURL里带个#号刷新不会404最简单二是让后端把所有非/api开头的请求都转发到index.html。我建议毕设直接选hash模式省去一堆配置老师不会因为你没有history模式而扣分。5. 论文写作顺序与答辩准备5.1 论文框架怎么搭很多同学写论文喜欢从第一章写到最后一章结果写到系统实现时发现代码和截图还没准备好又回头补来来回回效率极低。我的经验是先写需求分析和技术介绍再写数据库设计然后写程序最后用截图和实际代码补系统实现章节。这样的好处是前面章节不依赖程序成品可以先形成文字系统实现章节有了实物之后写起来又快又真实。论文章节结构可以参考下面的框架章节内容要点篇幅建议摘要研究背景、采用技术、实现功能、结果1页第1章 绪论项目背景与意义、国内外现状、主要工作3-5页第2章 相关技术SSM框架、Vue、MySQL、ECharts3-4页第3章 需求分析可行性分析、功能需求、用例图、非功能需求4-6页第4章 系统设计总体架构、功能模块、业务流程、数据库设计5-8页第5章 系统实现各功能模块实现过程、页面截图、核心代码8-12页第6章 系统测试测试环境、测试用例表、结果分析3-4页结论与展望总结成果、不足、后续改进方向1-2页参考文献不少于15篇1-2页数据库设计章节是老师的重点关注区域我建议把每张表的字段说明都用表格列出来并画一张简单的ER图再附一段建表SQL。这样评委老师一眼就能看出你数据库设计是认真做了的而不是把代码里的实体类抄一遍。5.2 答辩高频提问与应答思路答辩是最后一个关卡也是很多同学最紧张的地方。根据我的经历和帮同学模拟答辩时收集到的题目临时停车收费系统的高频提问基本集中在以下几类。第一类是框架原理题比如“SpringMVC执行流程是怎样的”“MyBatis中#{}和${}的区别”。这类题就是考察你有没有真正用过框架把执行流程背一遍即可重点是提到DispatcherServlet、HandlerMapping、Controller、ViewResolver这几个核心组件。第二类是业务逻辑题比如“停车费用是怎么计算的”“跨天停车怎么算钱”。这类题我建议直接白板画时间线边说边画入场时间在这里出场时间在这里中间减掉免费时长剩余部分按阶梯算。讲到跨天时画一条跨过零点的时间线强调按天拆分累加同时提到日封顶。这个回答方式很直观老师一般不会再深挖。第三类是设计思路题比如“为什么收费规则要单独建表”“为什么停车记录表里status和exit_time要同时存在”。这些问题的本质是考察你有没有思考过“可扩展性”和“数据一致性”。你只要回答“为了后续调整价格不用改代码”“为了区分在停车辆和历史记录”基本就能过关。6. 毕设避坑实录与时间规划6.1 高频报错速查表这个项目里我遇到过的典型报错整理成了一张速查表送给正被报错折磨的同学报错现象常见原因解决办法启动Tomcat后访问页面404部署路径不对或没配context path检查访问URL是否包含项目名前端请求后端报跨域前后端端口不一致配置Vite proxy或后端CORS数据库时间差8小时连接串没带时区参数URL添加serverTimezoneAsia/ShanghaiMyBatis报Invalid bound statementmapper XML没被打包pom.xml中配置resources包含mapper目录前端npm install卡住默认源速度慢换成镜像源后重新安装Vue打包后刷新404history模式没有后端路由兜底改用hash模式金额计算出现0.30000000000000004用了float或double全部改成BigDecimalTransactional不生效Service被同类内部调用事务方法通过代理调用拆到不同类第八个问题值得一提。很多人给Service方法加了Transactional但发现事务根本没生效排查半天才发现是因为在同一个类里一个方法直接调用了另一个带事务注解的方法导致事务代理没起作用。这个坑非常隐蔽答辩现场也很难想到但你知道原因之后下次写代码就会主动规避。6.2 各阶段时间安排建议毕设最怕的就是拖延。我见过太多同学前期觉得时间充裕天天刷手机到提交前一个月才开始慌最后只能花钱找人代做或者通宵赶工。按12周的周期来安排我是这样分配的第1到2周定题加技术预研把SSM整合和Vue环境的Hello World跑通第3到4周做需求分析和数据库设计把表结构和接口文档定下来第5到7周写后端接口每写完一个模块就顺手用Postman测试第8到9周写前端页面并做前后端联调开始准备答辩用的演示数据第10到11周写论文初稿并完成系统测试最后一周改论文做答辩PPT查漏补缺。最后再分享一个个人觉得很实用的小技巧开发过程中每完成一个功能模块就顺手截一张图存到一个专门的“截图素材”文件夹里按功能命名。等到写论文系统实现章节的时候你会发现这些截图就是你最好的原料不需要重新打开系统、造数据、截图写作效率直接翻倍。我当时就是靠这个习惯论文初稿比别人少花了将近一周时间。毕设这件事拼的不是谁聪明而是谁规划得好动手得早。