每年到毕设季XX管理系统都会准时霸屏。但同样是管理系统选题选得好不好直接决定后面写论文和答辩的时候是舒服还是遭罪。如果你正在纠结选什么题或者已经锁定了企业车辆管理系统这个方向那么这套基于SpringBoot、Vue和MySQL的实现思路应该能给你省下大量自己瞎摸索的时间。我不是来卖源码的而是把这类毕设从选题、建库、写代码到部署答辩的完整链路梳理成一套可以直接照着走的方法论。无论你是第一次接触前后端分离还是已经有点基础想找一份完整的参考实现这篇文章都适用。很多同学一看到管理系统就觉得土觉得满大街都是没新意。但企业车辆管理系统恰恰是那种边界清晰、业务丰富、难度刚好卡在够得着又不至于躺平的经典选题。它里面既有最基础的增删改查又有审批流、费用台账、到期提醒、统计图表这些能写进论文加分项的功能还跟现实企业的行政后勤需求挂得上钩——需求分析那章不至于编不出来。这套技术栈也相当成熟SpringBoot负责后端接口Vue负责前端页面MySQL存数据网上资料多得看不完遇到问题基本都能搜到答案。1. 选题逻辑为什么企业车辆管理系统是毕设的稳赚选择1.1 先搞清楚企业车辆管理的真实业务场景很多同学在选题之前根本没接触过企业里车辆是怎么管的。其实你不需要去企业实习过只要把它理解成一个围绕车辆资产和用车过程的台账系统就够了。一家稍微有点规模的公司日常用车场景大概是这样员工要外出办事先填一张用车申请单写明去哪、去多久、用什么车部门负责人或者行政调度员审批通过之后分配司机和车辆司机出车回来之后登记里程数、加油费用车辆自身的油费、维修费、保险费、年检记录也要一笔笔记下来。到了月底行政要统计每个部门用了多少次车、花了多少钱给财务做分摊。把这些场景翻译成系统功能就是下面这张表业务环节功能模块核心数据车辆基础信息车辆档案管理车牌、品牌、型号、购置日期、座位数、状态人员信息司机与部门管理司机姓名、驾照类型、联系方式、所属部门用车过程申请、审批、派车、归还用车时间、目的地、事由、审批状态费用与维护加油、维修、保险、年检台账金额、日期、单据号、到期时间统计分析用车统计、费用报表部门用车次数、月度费用汇总功能点列出来之后你会发现这个系统天然就覆盖了管理类毕设的四件套信息管理车辆、人员、流程审批用车申请、台账记录加油维修、统计报表数据汇总。业务不复杂但样样齐全写需求分析、画用例图的时候素材非常充足。1.2 为什么这条技术路线踩在毕设评分的舒适区毕设论文的评审和答辩说白了看的不是你的功能有多花哨而是三件事需求是不是清楚、设计是不是合理、工作量是不是够。企业车辆管理系统在这三件事上都占便宜。一是需求清楚。评委不用你解释就知道企业为什么要管车辆车辆有哪些信息需要录用车为什么需要审批。这意味着答辩的时候你不需要花大量口舌去铺垫业务背景直接讲技术实现就行。二是设计合理。系统的信息维度非常工整车辆是一对多挂司机和历史记录审批是典型的状态流转台账是标准的主表加明细结构。画E-R图、设计数据库表的时候关系非常自然不会出现那种为了凑关系硬造关联的尴尬。三是工作量可以灵活控制。如果时间紧砍掉统计图表和消息提醒做一个纯粹的CRUD系统也能过关如果想让论文好看加一个ECharts的部门用车统计大屏、加一个保险年检到期自动提醒成本不高但写出来非常能撑场面。既不会简单到被质疑工作量不足又不会难到做不完。2. 技术选型拆解SpringBootVueMySQL这套组合拳的取舍2.1 为什么选SpringBoot而不是SSH或SSM选技术栈的时候最忌讳的是跟风最怕的则是图老。如果你翻到十年前的老教程很多车辆管理类的毕设还是SSH架构也就是Struts2加Hibernate加SpringXML配置能写几百行光把环境跑起来就很崩溃。后来流行SSM也就是SpringMVC、MyBatis、Spring比SSH清爽了不少但各种配置依然繁琐。SpringBoot最核心的贡献是把配置变成了约定。内嵌Tomcat、自动装配、起步依赖一个starter就能把数据源、Web、MyBatis全部拉进来。对于毕设这种以功能实现为核心的场景开发效率不是一个量级的。而且SpringBoot本身就是现在企业里最主流的基础框架写进简历既不丢人也能证明你学的是当下的东西不是学了一门过时技术。版本选择上我建议锁死SpringBoot 2.7.x不要为了追新去用3.x。原因很简单3.x把javax换成了jakarta命名空间很多毕业设计爱用的教程、插件、杂七杂八的依赖可能还停留在2.x的写法你照着敲就会莫名其妙报一堆编译错误。用2.7兼容性最好网上搜问题的结果也最多。JDK就搭配1.8或者11稳定至上。2.2 Vue加Element UI做后台管理系统的天然优势后端选好了前端这边既然标题写了Vue方向就很明确了。我的建议是如果这是你第一个正经的前后端分离项目直接用Vue 2加Element UI别犹豫。Vue 2虽然官方已经进入维护后期但生态里沉淀下来的资料多得夸张。你写一个表单验证报错了、路由跳转失效了、axios拦截器配置不对搜索引擎一搜全是别人踩过的坑。配上Element UI那套现成的表格、表单、对话框、分页组件哪怕你CSS水平停留在能换颜色的程度也能拼出一个看着很专业的管理后台界面。Vue 3加Element Plus当然更好组件性能、组合式API的写法都更现代如果你已经比较熟练完全可以上。但如果你是拿这个项目来练手的第一站诚实建议选Vue 2把精力集中在业务逻辑上而不是在setup、ref、reactive这些新语法里消耗心态。前端状态管理方面一个中度复杂的管理系统其实用不着上Vuex全家桶。登录之后把用户信息、角色、路由菜单存到store里日常组件之间通信靠props和事件总线就够用了。把简单问题复杂化是新手最容易犯的毛病。2.3 一次完整请求从浏览器到数据库的协作流程很多人前后端分离项目做完了问他一次请求是怎么跑通的支支吾吾说不清楚。这属于必须吃透的基础。用户在浏览器里打开系统Vue项目通过axios向后端发请求的时候整个链路是这样的Vue组件的methods里调用axios.get或者axios.post请求带着URL和参数打到SpringBoot的ControllerController收到请求后调用Service层处理业务逻辑Service再调用Mapper层也就是MyBatis-Plus操作MySQL数据库数据库把查询结果返回给MapperMapper把它装配成实体对象返回给Service再返回给ControllerController把对象转成JSON格式响应给前端Vue拿到数据后渲染到页面上。这个链路用生活里的场景类比就像你去餐厅吃饭Vue是餐桌前的你负责提出需求、展示结果Controller是前台服务员负责接单、传话Service是后厨的总管负责指挥做菜的逻辑Mapper是具体切菜配菜的厨师直接跟食材存储间打交道MySQL就是那个存储间。理解了这个流程后面无论是调接口出Bug还是答辩论证你都能清晰地定位是哪一环出了问题而不是只会把完整报错截图甩给搜索引擎。3. 数据库设计车辆信息、审批流和费用台账的表结构推演3.1 核心主数据表用户、部门、车辆、司机数据库设计是整个系统的地基地基歪了代码写再多也是空中楼阁。设计的时候不要一张表打天下而是按照业务对象拆分成多个主数据表。用户表sys_user、部门表sys_dept、角色表sys_role是权限和归属的基础。用户表里username做唯一索引password字段一定不要存明文用BCrypt加密后的字符串。很多同学图省事存了明文密码答辩时一旦被问到密码安全问题当场就扣印象分。车辆表vehicle_info的字段设计我建议参考行驶证上的信息来plate_no车牌号、brand品牌、model型号、color颜色、seat_num座位数、engine_no发动机号、vin车架号、buy_date购置日期、status当前状态。status是一个非常关键的字段我用一个整数枚举来表示0空闲、1已出车、2维修中、3已报废。为什么用整数而不是字符串因为程序里好判断、数据库里好索引写论文说明设计理由的时候也显得你考虑过状态值的存储问题而不是随便拿个字符串怼上去。司机表driver_info关联用户表因为司机本身也是系统的一个用户但司机有额外的属性驾照类型、驾驶证号、准驾车型、从业资格有效期。这种公用信息放主表、私有信息放子表的拆分方式就是第三范式的应用答辩证问到设计依据的时候很好讲。3.2 审批流相关的两种建模方式单表状态与独立记录用车申请是整个系统的业务核心它的表结构设计有两个层次我建议能力允许的话直接做第二种。第一种是简单模式一张用车申请表里面加一个status字段从待审批、已通过、已拒绝、出车中到已归还用一个字段标识当前状态。这种设计的好处是查数据方便缺点是审批历史被覆盖了只知道最后一步是谁批的看不到中间过程。适合工作量拉不满、目标仅仅是能跑通的情况。第二种是推荐模式用车申请表vehicle_apply只管申请本身所有审批动作单独放到审批记录表approve_record里。车辆申请表关注当前状态在哪审批记录表关注每一步谁在什么时候做了什么决定。两张表配合既能查到一辆车当前的审批状态又能回溯完整的审批链路。费用没增加多少但论文里可以光明正大地写一章审批流设计答辩追问历史记录的时候也站得住脚。apply表的关键字段不外乎这几项申请人ID、申请部门、用车事由、目的地、计划开始时间、计划结束时间、申请车辆ID、当前状态、创建时间。审批表则是申请ID、审批人ID、审批结果、审批意见、审批时间。状态流转我用了一组常量来定义1待审批、2已通过、3已拒绝、4已出车、5已归还、6已取消。把所有状态值集中定义在一个常量类或者枚举里是Controller和前端页面上判断状态的唯一依据散落字符串全靠肉眼对比是新手最容易踩的坑。3.3 费用台账加油、维修、保险、年检怎么挂靠车辆车辆不是录进系统就不管了它的生命周期里会产生大量费用和证照节点这些都要按台账来管理。加油记录表fuel_record车辆ID、加油日期、加油量升数、加油金额、加油站、经办人。维修保养表repair_record车辆ID、维修日期、维修类型保养、小修、大修、事故维修、维修项目描述、费用、维修厂、经办人。保险表insurance_record车辆ID、保险公司、保单号、险种、生效日期、到期日期、保费。年检表inspect_record车辆ID、年检日期、到期日期、检测站、年检结果。这几张表有一个共同点都是多对一挂在一辆车底下的流水记录。一张车对应多条加油记录、多条维修记录这种主从结构在数据库层面就是加一个vehicle_id外键在业务层面就是车辆详情的Tab切换。你在前端做一个车辆详情页——上面是车辆基本信息下面是加油、维修、保险、年检四个Tab数据全查出来了。这个功能视觉效果很足论文截图也好看。到期提醒功能依赖的是保险和年检的到期日期。实现方式不复杂用SpringBoot的Scheduled注解写一个定时任务每天凌晨扫描一次这两张表找出未来30天内到期的记录插入一张通知表里。用户登录后首页一查通知表就有小红点。这个功能从数据库到代码到交互都干干净净是我强烈建议加进去的加分项。3.4 索引、外键和冗余字段评委最爱问的几个设计细节数据库设计光建表是不够的能解释清楚设计决策才算真的懂。索引的选择方面。车牌号、用户名、申请状态、日期字段这几个查询频率最高的字段都应该建索引。车牌号做唯一索引因为它不可能重复申请表的vehicle_id和create_time考虑建联合索引因为业务场景经常是查某辆车某段时间的申请记录。需要说明的是索引不是越多越好每建一个索引插入更新数据时就要多维护一棵B树毕设这个小体量用不到太多索引把高频查询覆盖住就够了。外键这块我建议只做逻辑外键不建物理外键。什么意思就是表结构里保留vehicle_id、user_id这些字段程序层面靠事务保证数据一致性但不在数据库层面声明FOREIGN KEY约束。原因很实际毕设项目增量数据少物理外键的约束能力体现不出来反而会在删数据、初始化数据、分批导入时带来一堆顺序上的麻烦。但你写论文的时候可以提一句考虑到外键约束对数据一致性的保证作用在实体关系上保留了外键关联这属于既做了实际取舍又能圆回来的表达。特点字段要适度冗余。比如申请单里除了user_id再冗余一个apply_user_name除了vehicle_id再冗余一个plate_no。为什么要冗余因为列表页要显示谁申请的什么车如果只用ID前端就得挨个查表翻译一次列表请求要额外拼七八个查询。多存一个名字字段查询一次就全出来了。这种反范式的冗余在管理系统中非常常见答辩时解释为以空间换查询效率即可。4. 业务模块实现要点审批流、到期提醒和权限设计这类加分项怎么做4.1 用车申请审批状态机把业务规则固化到代码里状态机这个概念听着高大上落到实处就是把状态的合法流转规则写清楚然后让代码强制执行。我对这个系统定义的状态转移是待审批可以被通过、被拒绝、被提交人取消已通过可以由调度员变成出车中出车中由司机或者行政操作变成已归还已拒绝状态不可再发起流转用户只能重新提一条新申请。代码层面怎么落地首先有状态常量类或枚举其次是在Service层写updateStatus方法方法内部用switch或者if判断当前状态与目标状态是否匹配不匹配就直接抛业务异常。比如一条已拒绝的记录不会被调度员误点成已出车因为后端在入口就把这种非法操作拦住了。前端页面的按钮显隐跟状态机一一对应待审批状态下申请人能看到取消申请审批人能看到通过和拒绝按钮已通过状态下调度员能看到派车出车按钮出车中能看到登记归还按钮。状态、按钮、接口三者的映射关系我在前端写了一个配置对象把每个状态对应的可用操作数组集中配置好页面渲染和按钮的v-if都从配置里取这样前端也不会出现按钮跟状态对不上的混乱。4.2 到期提醒、统计报表和首页图表撑起论文截图的功能点很多管理类毕设的痛点是功能都有但看起来太平淡。解决这个问题只需要三个小功能到期提醒、月度费用统计和首页图表。到期提醒的具体做法前面提到过定时任务扫描保险和年检的到期日期。光有通知还不够你要在车辆列表上做视觉强化每行车辆如果存在30天内到期的记录就在车牌号旁边渲染一个红色的待年检或者保险将到期标签。实现方式是车辆列表查询的时候顺便关联查一下保险表和年检表取最小到期日跟当前时间比。这个效果不需要什么高深技术但截图放在论文里非常直观一看就知道系统是有智能的。统计报表用ECharts画两个图就够。一个是柱状图各部门用车次数统计SQL就是SELECT dept_name, COUNT(*) FROM vehicle_apply GROUP BY dept_name一个是折线图最近6个月加油费用趋势SQL也差不多。把结果集封装好返回前端ECharts几分钟就能画出来。这两个图放在Dashboard首页系统整体观感立刻就不一样了。4.3 RBAC权限设计为什么不同角色看到的菜单不一样权限控制是评委几乎必问的点。我不建议你在毕业设计里做细粒度的按钮级权限做到菜单级就足够了。实现方式是经典的RBAC模型也就是用户-角色-菜单三张表。sys_user里存role_id角色表里存role_code比如admin管理员、dispatcher调度员、user普通员工还有driver司机。登录成功后后端根据角色ID查出这个角色能访问的菜单树返回给前端前端根据菜单数据动态生成侧边栏。路由那边配合路由守卫判断当前用户有没有权限进入某个页面没有就直接踢到403页面。接口层面也不要裸奔。我写了一个简单的拦截器或者直接用Spring AOP切面check登录状态和角色权限方法上标注RequireRole(dispatcher)切面里判断当前用户角色是否匹配不匹配返回403。这么一套做下来权限设计从数据库到前端到后端全链路闭环答辩的时候从用户表怎么设计一路聊到路由守卫怎么拦截你都能接得住。4.4 事务一致性的处理一个容易被忽视的扣分点这个点是很多同学做财务台账时容易翻车的把加油记录插入到fuel_record表的同时要不要同步更新车辆表的累计加油金额这个场景我用事务来解决因为插入记录和更新汇总必须是原子的要么都成功要么都失败。在SpringBoot里加一个Transactional注解方法执行过程中抛出运行时异常事务自动回滚数据不会出现流水记了但汇总没加的半截状态。答辩时如果被问并发问题你考虑了吗你可以说加油记录插入前先对车辆表加一把悲观锁或者乐观锁版本号防止两个人同时录入导致金额覆盖。能说出这两种锁的区别这个问题的分基本就拿到手了。虽然毕设系统几乎不会真的有并发压力但考虑过和完全没想过在答辩观感上是天壤之别。5. 部署、论文和答辩的无缝衔接5.1 从本地开发到云端部署的完整链路本地跑通只是第一步能部署到云服务器上给评委现场演示效果比PPT强十倍。部署链路很成熟照下面走就行。后端打包在项目根目录用Maven执行mvn clean packagetarget目录下会生成一个xxx.jar包。启动命令是java -jar xxx.jar只要服务器环境有JDK 1.8或11就能跑。数据库配置外置到application-prod.yml里端口、数据库地址、数据库账号密码都放配置里启动命令追加--spring.profiles.activeprod即可切换环境。前端部署有两种方式。第一种是直接把npm run build生成的dist目录拷到SpringBoot的static目录下这样后端jar包本身就成了一个包含前端页面的单体应用访问同一个端口就行天然不存在跨域问题。这种方式对于毕设来说最省事部署成本最低。第二种是前端部署到NginxNginx负责托管静态资源和转发/api开头的请求到后端端口。这种方式更接近企业真实做法你可以在论文里写前端采用Nginx反向代理后端服务独立部署听起来专业。数据库初始化不要用Navicat手动点把建表和初始化数据写成一份sql脚本导入的时候mysql -u用户名 -p密码 -h地址 数据库名 init.sql 一行搞定。初始数据一定要准备充分至少五辆车、十个用户、几十条申请记录、几条保险年检到期数据。这样打开首页就有东西看图表也有数据渲染答辩演示的时候不会面对一片空白。5.2 毕业论文的章节架构与工作量呈现论文的章节结构不用标新立异按学校模板来最稳妥但内容填充有讲究。摘要部分用一两句话点题针对企业车辆管理中存在的信息分散、审批流程不规范、费用统计困难等问题设计并实现了一套基于SpringBoot和Vue的企业车辆管理系统。这句话前半句是问题背景后半句是技术方案足够评委抓取关键信息。需求分析章节把前面业务场景的那张表整理成用例图加文字描述每个核心功能对应一个用例说明。系统设计章节画系统架构图、功能模块图、E-R图E-R图用PowerDesigner或者draw.io画得干净一点这部分是论文的门面。数据库设计章节把每张表的字段名、字段类型、约束、备注整理成一张大表格工作量直接拉满。系统实现章节不需要每页代码都贴上选核心的审批状态机、定时任务、权限拦截器三个点重点贴代码段其余用界面截图加功能说明带过。系统测试章节用表格列出测试用例编号、测试步骤、预期结果、实际结果写十到二十条就够撑场面。论文后面附录贴核心代码的时候注意控制篇幅不要几万字全堆上去抽取核心类和关键方法即可。5.3 答辩现场的追问清单与应答思路提前把评委可能问的问题列出来给自己准备答案是答辩准备最有效的方式。为什么选这个选题标准答案是企业车辆管理是行政后勤的刚需场景目前很多中小型企业仍依赖Excel登记存在数据分散、流程不透明、费用统计困难的问题所以选取该场景。这个回答既回答了选题动机又给了系统存在价值。为什么用SpringBoot而不用SSH回答要点SpringBoot简化了配置负担提供了自动装配和内嵌容器能力开发效率更高并且是当前企业应用的主流选择有利于后续技术衔接。审批状态你是怎么设计的直接把状态机画在黑板上待审批可以流转到已通过、已拒绝、已取消已通过到出车中出车中到已归还。再补充一句非法状态跳转会被后端拦截。密码为什么用BCrypt回答因为BCrypt是自适应哈希算法能抗彩虹表攻击每次加密生成的哈希值不同比直接MD5更安全。项目用的是Spring Security自带的BCryptPasswordEncoder。数据库表之间为什么不用物理外键回答物理外键会降低数据初始化灵活性并增加删除复杂性本系统在实体关系设计上保留外键语义通过事务和业务逻辑保证一致性。这个回答既务实又不显得你完全不懂外键。5.4 演示系统的操作脚本别在台上手忙脚乱答辩演示环节最常见的翻车是被追问某个功能然后现找菜单页面一顿乱点找不到。我的办法是提前准备一份演示脚本把演示流程固定下来。演示顺序我建议设计成一条完整的故事线登录页面展示普通员工视角看到申请页面和自己的待办提一条新用车申请切换账号登审核员审批通过切换调度员账号派车出车车辆状态变为出车中司机账号登记归还里程增加进车辆详情页看加油记录、维修记录展示保险即将到期的红色标签回首页看统计图表——部门用车柱状图、加油费用趋势切管理员账号看系统管理菜单里的用户分配和角色管理。这条线走下来大概十分钟但把全部核心功能都覆盖了评委基本没有机会逼你临时乱翻。脚本里把每个步骤要说的关键台词也写上一两句手稳心不慌。6. 踩坑实录三个最典型问题的完整排查链路6.1 跨域问题前端调接口一直报CORS错误场景描述前端Vue项目跑在8080端口后端SpringBoot跑在8081端口页面上点击登录控制台报错Access to XMLHttpRequest has been blocked by CORS policy。排查思路打开浏览器F12切到Network面板看到请求状态是失败的响应头里没有Access-Control-Allow-Origin字段。问题的本质是浏览器的同源策略——协议、域名、端口任何一个不同跨域就会被拦截。解决过程我先后试过在Controller上直接加CrossOrigin注解发现每个接口都加一遍很啰嗦后来做成全局的CorsFilter在配置类里统一放行。开发阶段我推荐用这个方案因为后端配置一次前端不需要动。生产部署时因为前后端合并或者用Nginx同源托管跨域问题自然消失。这个思路要在论文测试章节里写清楚说明你理解跨域的前因后果而不是只会贴个配置。6.2 时间字段差8小时数据库时间和页面时间对不上场景描述往表里插入一条申请记录数据库里存的时间是正确的前端页面查出来显示的时间少了8小时登录时间和创建记录时间全都对不上。排查思路先确认JVM本地时间正常再查MySQL连接串。问题根源是MySQL连接的serverTimezone参数没指定默认按UTC时区处理中国是东八区UTC时间比北京时间早8小时于是显示出来的时间就回到前一天。解决过程在jdbc连接URL末尾加上serverTimezoneAsia/Shanghai重启服务后时间正确。另外还处理了JSON序列化层面的时间格式问题Jackson默认输出时间戳或者格式不太友好我在application.yml里配置了spring.jackson.date-format和time-zone统一输出yyyy-MM-dd HH:mm:ss格式这样前端拿到的时间字符串直接就能用不用再自己格式化。这个坑几乎人人会踩踩过一次就记住了。6.3 MyBatis-Plus字段映射实体类的驼峰属性查出来是null场景描述用MyBatis-Plus的selectList查车辆列表数据库字段create_time、buy_date这些带下划线的字段在实体类里对应的驼峰属性createTime、buyDate全是null查出来数据丢失。排查思路这是典型的ORM字段映射问题。Java属性是驼峰命名数据库列是下划线命名默认情况下MyBatis不会自动把这两者对上号需要打开驼峰映射开关。解决过程在application.yml里配置mybatis-plus.global-config.db-config.map-underscore-to-camel-case: true或者更省事的做法——因为MyBatis-Plus新版默认打开了这个映射如果你项目里关闭过全局配置就会踩坑。另外检查实体类字段上是否没有加TableName和TableField注解实体类对应的表名如果跟类名不一致也要用注解显式指定否则MyBatis-Plus会把驼峰类名转成下划线表名去查表不存在直接报错。这三个坑的共同特点是单独拿出来都不难但没有排查思路的人会浪费一整晚在搜索引擎里来回跳。把它们写进论文的系统调试与问题解决章节反而是证明你独立排错能力的素材。7. 最后说点实际的体会我从大二开始跟着老师做过企业信息化的横向项目后来自己毕业设计选的就是类似方向这几年也断断续续帮学弟学妹review过不少管理类毕设。要说最大的体会就是这类系统想做到能过很容易但想做到舒服地过靠的还是对每一个设计决策多问一句为什么。把SpringBoot、Vue、MySQL这套组合吃透你知道的不只是三个孤立的技术名词而是理解了浏览器到数据库之间数据流动的完整链路。把审批状态机设计清楚你学的不是一两句if判断而是如何把业务规则固化到代码里的一种思维方式。把数据库表拆分成主数据、审批流、台账三种类型你掌握的是几乎所有企业信息系统的通用骨架。所以我不太建议直接买一份源码就交差。买来的源码你连包结构都说不清楚答辩的时候评委随便问一个这个查询为什么这么写就露馅了。照着前面这条链路自己敲一遍哪怕慢一点代码写得笨一点只要能讲出每张表、每个接口、每个状态背后的理由这个毕设就是你真的做了、真的会了。这几年我带过的人里凡是踏踏实实从建表开始做的没有一个答辩不是轻松过关的。祝你们也能顺顺利利完成这套企业车辆管理系统拿到自己满意的成绩。
