企业官网建设流程全解析

每年毕业季，都有大量同学卡在选题这一步。二手车租赁这个方向，看着像是个管理系统，实际上牵扯到多角色权限、订单状态流转、支付流程、车辆状态管理这些真实业务问题，用来做毕设天然合适——它不像纯商城那样烂大街，也比单纯CRUD系统能多展示一些思考深度。而Java+Vue+SpringBoot这个组合，恰好是目前国内中小型公司使用率最高的技术栈之一，做完即简历经验，面试还能直接拿来当项目讲。

这篇内容我按开题报告加实际落地的双重视角来写，覆盖从选题理由、功能拆解、数据库设计、核心代码思路到环境配置、答辩避坑的完整链路。无论你是已经定题正在写开题报告，还是刚有这个想法还在犹豫，下面这些内容都可以直接参考。

1. 选这个题的底层逻辑与技术选型分析

1.1 为什么"二手车租赁"比"某某管理系统"更适合做毕设

很多同学选题时习惯选"图书馆管理系统""学生信息管理系统"，这类题目的问题在于：业务太浅、边界太清晰，一眼看到底，论文写不满，代码也没法展示亮点。二手车租赁平台不一样，它天然具备几个适合做毕设的要素：

第一，角色复杂。平台至少涉及管理员、商家（车源提供方）、普通用户（租车人）三类角色，每类角色的权限、功能、页面都不同，这就能自然引出Spring Security或Shiro的权限控制设计。而在论文里，"多角色权限设计"是一个公认的、有分量的研究点。

第二，业务有状态流转。一辆车从上架到下架，一个订单从提交到完成，中间有大量状态变化和分支处理——车辆被预约了能不能再被下单？用户还车时超时了怎么计费？押金什么时候退？这些问题让系统不再是简单增删改查，而是需要认真设计状态机。

第三，贴近真实市场。二手车租赁在当前国内确实有需求场景，共享出行、短途自驾、长租替代购车这些概念都在推这个市场，写开题报告的"选题背景"和"研究意义"时，素材容易找，也能写实。

选对业务方向，开题报告等于完成了一半。另一半，就是选对技术栈。

1.2 Java+SpringBoot+Vue组合为什么是当前最优解

先看语言层面。Java在高校课程体系里覆盖率最高，大部分计算机相关专业都系统学过Java基础、面向对象、集合框架，基础门槛低。更关键的是，Java在就业市场的需求量依然排在最前列，用Java做毕设，等于提前用项目把语言基础重新过了一遍，秋招面试时被问到Java基础、JVM、集合源码的概率很高，做过真实项目的人回答起来明显更有底气。

再看框架层面。Spring Boot解决的是Java后端开发中配置繁琐、部署复杂的问题。它在Spring和Spring MVC基础上做了大量自动配置，内嵌Tomcat，打成一个jar包就能跑，特别适合毕设这种需要快速出成果的场景。而且Spring Boot的生态极其完善——操作数据库有Spring Data JPA或MyBatis，安全认证有Spring Security，接口文档有Swagger，几乎你能想到的功能都有现成的starter可以集成。

前端这块，Vue的学习曲线相对平缓，中文文档齐全，社区资料丰富。Vue的核心思想是数据驱动视图，你只管维护数据，DOM的更新交给框架处理，这点对后端思维为主的同学特别友好，不需要像操作原生DOM那样关注页面细节。配合Element UI这类组件库，后台管理页面可以快速搭出来，而且颜值在线，答辩演示时观感很好。

这三者组成的全栈组合，覆盖了从前端页面、后端接口、数据库设计到服务器部署的完整链路。对这个组合的理解，我在开题报告里是这样写的：前端通过Axios发起HTTP请求，后端Controller接收请求并调用Service层处理业务逻辑，Service再通过Mapper（MyBatis）或Repository（JPA）操作数据库，处理结果以JSON格式返回前端渲染——各层职责清晰、耦合度低，既符合企业级开发的分层规范，也让论文可以按层次展开论述。

2. 开题报告怎么写才不虚：框架、技巧与核心章节要点

2.1 开题报告的整体结构与每部分写法

开题报告的评审老师最看重三件事：选题有没有意义、你知不知道别人做到什么程度了、你的技术方案是不是可靠可行。围绕这三点，开题报告一般包含以下章节：

选题背景与研究意义：这一部分要回答两个问题——为什么做这个题目？做了有什么价值？背景从大环境写到小需求，比如国内二手车交易规模逐年增长、短租自驾需求上升、传统线下租赁存在信息不透明和效率低的问题。研究意义分理论意义和实际意义，理论意义落在"设计并实现一个前后端分离的租赁信息管理平台"，实际意义落在"提高车辆资源利用率、简化租车流程、为同类系统提供参考"。

国内外研究现状：文献综述是很多同学的弱项，但偏又是老师必看的部分。写这部分的核心技巧是：不要抄摘要，要提炼讲"别人做了什么系统、解决了什么问题、还有什么不足"。比如有文献做了基于SSH的租车系统，但架构较老、用户体验一般；有研究做了基于Android的租车应用，但覆盖的是移动端，缺少后台统一管理。把这些"不足"列出来，自然引到你的方案——前后端分离、响应式页面、多角色管理，你的创新点就出来了。

研究内容：这一块直接对应你系统要做什么，一般分三个方面写——前端展示层做什么、后端业务层做什么、数据库设计做什么。

技术路线与方案：画出你的技术架构图并配上文字说明，讲清楚每个组件的作用。这里有一个加分技巧：不要只堆技术名词，要写清楚为什么选它。比如MySQL为什么不用Oracle？因为开源免费、轻量、满足毕设数据量需求，且是互联网行业主流。

进度安排：按学校要求的周期排计划。常规排法：第1-2周需求分析与文献调研，第3-4周数据库设计与接口设计，第5-7周后端开发，第8-9周前端开发与联调，第10周系统测试与修复，第11周撰写论文，第12周准备答辩。

2.2 系统角色划分与功能模块拆解

系统功能设计的核心思路是按角色拆需求。我在开题报告里把用户分成三类，每个角色对应一套独立的功能清单：

管理员：平台的管理中枢，负责基础数据维护，包括用户管理（审核、禁用、重置密码）、车辆信息审核（商家上传的车源需要审核后才能上架）、订单监管（查看所有订单、处理异常订单）、数据统计（车辆数量、订单量、成交额等）。

商家（车辆提供方）：负责车源信息的发布，包括车辆新增（填写品牌、型号、里程、日租金、押金、车况描述、上传照片）、车辆上下架管理、订单处理（确认接单、确认还车、处理违约）、收入查看。

普通用户（租车人）：核心业务方，功能包括注册登录、浏览车辆、按品牌/价格/座位数筛选车辆、租赁下单、在线支付（可选模拟支付）、发起还车、评价车辆、查看个人订单和押金状态。

这种按角色拆需求的方式有两大好处：在论文里可以画出清晰的用例图，功能边界一目了然；开发时也可以按角色划分迭代计划，先做完一个角色的全部功能再做下一个，避免开发到一半发现需求打架。顺便说一句，答辩时老师最喜欢问的一个问题就是"你这个系统的访客和首页展示逻辑是什么"，提前把角色边界想清楚，就不用担心被问住了。

2.3 "创新点"怎么提炼才不虚不假

毕设答辩最尴尬的场景，就是老师说"你这个系统也没什么新的东西"。提前在开题报告里把创新点想好，后面写论文照着展开就行。结合这个选题，我建议从三个方向提炼：

业务上的小创新：比如在车辆推荐上，可以按照车辆浏览量和订单完成数做一个简单的热度排序；在订单计价上，支持日租、时租两种计费模式，超时部分按小时加收费用——这些逻辑不复杂，但比纯固定价格有看点。

技术上的小创新：比如引入Redis缓存车辆热门数据，用JWT实现无状态登录认证，用WebSocket实现站内消息通知（下单后商家实时收到提醒），每个点都能写一段技术说明。

交互上的小创新：比如前端车辆筛选支持多条件组合筛选并即时刷新列表，车辆详情页采用图片轮播，订单流程以步骤条形式直观展示当前状态。这些实现成本低，但演示效果好。

注意，创新点不要贪多，开题报告里写2到3个就够，关键是每一个都能展开说清楚实现原理，写到论文里也都有实实在在的代码支撑。

3. 数据库与核心业务流程设计：决定项目高度的关键环节

3.1 核心数据表设计与字段要点

数据库设计是论文里的硬核部分，也是答辩老师重点问的区域。我按第三范式设计，同时允许少量冗余换性能。系统核心表包括：用户表（区分管理员、商家、用户三种角色）、车辆表、订单表、评价表、公告表、收藏表。下面重点说三张核心表。

用户表在基础字段之外，关键是role字段区分角色，我用了int类型，0管理员、1商家、2用户，配合一个status字段做账号状态（是否被封禁）。密码存储用BCrypt加密，这个在Spring Security里可以直接用。

车辆表字段较多，但要抓住关键：car_name（车辆名称）、brand（品牌）、category（车型分类，如轿车/SUV/MPV）、seats（座位数）、gearbox（手动/自动）、daily_rent（日租金，单位元）、deposit（押金）、car_status（0待审核、1已上架、2已下架、3出租中），另外还有license_plate（车牌）、mileage（里程）、color、year（上牌年份）、description（车况描述）、cover_image（封面图）、images（多图，存JSON数组或逗号分隔的路径）。

这里有个很容易踩的坑：car_status这个字段会在车辆表里出现，但订单表里也有一个status，两个status的意义完全不同。车辆表status表示车辆当前能否被租，订单表status表示订单流程走到了哪一步。设计表时一定要把注释写清楚，不然代码写到一半自己就先分不清了。还有一个小建议：日租金和押金用DECIMAL(10,2)，不要用FLOAT或DOUBLE，金额字段用什么类型这种小细节，答辩时经常被细心的老师指出来。

订单表是业务核心，字段包括order_no（订单编号，用时间戳加随机数生成，保证唯一）、user_id（租客ID）、car_id（车辆ID）、merchant_id（商家ID，冗余存这个方便商家端查询自己的订单）、start_date（预计取车日期）、end_date（预计还车日期）、total_amount（订单总额）、deposit（本次订单押金）、status（0待支付、1待商家接单、2租赁中、3待归还、4已完成、5已取消、6异常申诉中）、create_time、pay_time、finish_time。订单状态流转我下面单独讲。

3.2 订单状态流转与状态机设计

订单状态是整个系统里最容易写乱的地方。我在第一版设计时偷懒，直接在Service层写if-else判断，结果状态一多代码就膨胀成一个几百行的面条代码，根本没法维护。后来重构时我画了一张状态流转图，把合法流转路径固定下来，代码也按这个结构改干净了。

合法流转路径长这样：用户提交订单（0待支付）→ 支付成功（1待商家接单）→ 商家接单（2租赁中）→ 用户发起还车或商家确认还车（3待归还）→ 管理员或商家确认车辆无异常（4已完成）；异常路径包括：支付超时取消、商家拒单、用户取消订单（5已取消）、还车时检查车辆有损坏或超时未还（6异常处理中，需管理员介入）。

把这个流转理清楚之后，后端代码可以这样设计：每执行一个动作（pay、confirmOrder、returnCar、complete），先校验当前状态是否允许该动作，再更新状态。Service里写一个validateStatus(currentStatus, expectedStatuses)的通用方法，非法流转直接抛业务异常，代码清晰，也容易写单元测试。这个点如果你写进论文里，画一张订单状态图，答辩老师基本都会觉得你考虑问题全面。

3.3 并发场景：同一辆车被重复下单怎么处理

这是一个很现实的问题，处理不好就会出现超卖：两个人同时看到一辆车空闲，同时下单，结果都成功了。解决思路有三种方案：

方案一是数据库层面加锁——在查询车辆状态时，使用SELECT ... FOR UPDATE锁定该行，事务提交后释放。但FOR UPDATE在高并发下性能一般，而且需要事务包裹，用完必须提交或回滚，对代码结构要求高。

方案二是乐观锁——车辆表加一个version字段，更新时校验version是否等于读取时的值，不等于则表示被别人改过，重试或提示失败。适合冲突较少的场景。

方案三是Redis分布式锁——用SETNX命令实现，适合分布式环境，但毕设阶段引入Redis会多一套环境依赖，有的同学电脑上没装Redis就会卡住。

我的建议是方案二，逻辑简单、不需要额外环境，答辩时也讲得清楚。核心SQL大致是这样：UPDATE car SET car_status = 3, version = version + 1 WHERE id = ? AND version = ? AND car_status = 1，如果影响行数为0，说明车辆状态已被其他事务修改，本次下单失败。把这条SQL的用意写进论文里，并发控制这块就直接拉满了。

4. 核心功能实现思路与关键技术点详解

4.1 车辆检索、筛选与前端实时联动

车辆列表页是整个系统访问量最高的页面，也是前端交互的重点。Vue端的实现逻辑是：页面加载时调用后端接口获取全部已上架车辆；用户选择筛选条件（品牌、车型、价格区间、座位数）时，通过this.$set更新查询条件对象，触发监听器重新调用接口；后端在Service层用MyBatis的动态SQL（<if>标签按条件拼接查询语句）完成多条件组合查询，按创建时间倒序返回。

这里有一个性能优化点：车辆列表接口不要一次返回所有字段，特别是那些几百字的description文本，列表页用不上，反而拖慢请求。我单独写了一个VO（View Object），只包含列表页需要的字段——车辆名称、品牌、封面图、日租金、押金、座位数、车型，点进详情页时再通过车辆ID查询完整信息。这种"列表轻、详情重"的设计，是实际开发里的常见思路，写进论文里也是一个体现工程经验的小亮点。

4.2 文件上传与图片展示实现细节

车辆照片上传是商家端的刚需功能。技术方案我选了本地存储加数据库存路径的方式：前端用Element UI的Upload组件接收文件，通过Axios以FormData格式POST到后端的/api/file/upload接口；后端用MultipartFile接收，校验文件大小（限制5MB以内）和扩展名（jpg、png、jpeg），然后用UUID重新生成文件名（避免中文名乱码和重名覆盖），按日期分目录存储，例如/upload/2025/06/01/uuid.jpg，最终把拼接好的访问路径保存到数据库。

这里有一个访问路径上的坑。开发环境下，前端运行在5173端口（Vite默认），后端运行在8080端口，图片上传后访问路径是localhost:8080/upload/xxx.jpg，前端页面要用http://localhost:8080前缀拼接完整路径才能显示。我在给前端返回数据时，直接在后端把图片路径拼成完整URL返回，前端拿到什么就展示什么，省去联调时来回对路径的麻烦。另外Spring Boot默认的静态资源路径classpath:/static/只能访问jar包内的文件，外部上传目录需要单独配置映射，在配置类里加一段WebMvcConfigurer把/upload/**映射到本地磁盘目录，否则上传成功但打不开图片。

4.3 基于JWT的用户认证与接口权限控制

登录认证这个模块，几乎每个上点规模的系统都绕不开。这个项目我选了JWT方案，逻辑比Session更直观，也方便前端做登录状态管理，具体实现是这样的：

用户登录成功后，后端用用户的ID和角色信息生成一个token串返回给前端。前端拿到后存在localStorage里，Axios请求拦截器统一在请求头中携带Authorization: Bearer <token>。后端自定义一个拦截器（HandlerInterceptor），拦截所有需要登录的接口，从token中解析出用户信息放入ThreadLocal或Request作用域，同时校验角色是否有权限访问该接口。

开发时有一个阶段我踩了坑：只在Controller方法上加@RequiresRoles注解（Shiro）做权限控制，结果管理员接口用普通用户token也能调通，排查半天发现是拦截器里只校验了token有没有，没校验角色。正确做法是：切面或拦截器里先解析角色，再看这个接口允许哪些角色访问，两者都通过才放行。这个模块的代码逻辑在论文的"系统安全设计"章节里是核心内容，写清楚能大大提升技术深度。

4.4 定时任务与模拟支付：让系统"闭环"两个加分项

很多毕设系统做到订单支付这步就停了，直接置为"已支付"，虽然能跑通，但答辩时显得很单薄。我在这里做了两件小事，既不难，又让系统显得完整很多。

第一件是集成支付宝沙箱支付。支付宝开放平台提供沙箱环境，只需要注册一个开发者账号，在沙箱应用里配置自己的公钥和私钥，后端集成官方SDK的alipay.trade.page.pay接口，用户下单后跳转到支付宝沙箱收银台，用官方提供的买家账号就能模拟真实支付流程，支付结果通过异步通知（notify_url）回传给服务器更新订单状态。整个过程半天就能接完，但效果是质的飞跃——答辩演示时可以给老师现场走一遍"下单-跳转支付-支付成功自动改订单状态"的闭环，这比一句"这里用模拟支付"有说服力得多。

第二件是数据统计模块。管理员端首页放一个统计面板：今日订单数、本月成交额、车辆总数、注册用户数，再画一个近7天订单量折线图（后端返回List，前端用ECharts渲染）。这个模块的SQL主要是COUNT、SUM、GROUP BY、DATE_FORMAT这些基础函数，难度不大，但功能上能让系统看起来更完整。更要紧的是，论文里的"系统测试"章节和"数据统计分析"章节都有内容可写了。

5. 环境配置与项目初始化全流程（含版本踩坑记录）

5.1 本地开发环境版本搭配

版本搭配是新手第一个拦路虎。我的建议是安装以下版本组合，这套方案我实测下来最稳定，网上资料也最多，遇到问题容易搜到解决方案：JDK 1.8（注意不是17，很多同学装最新版JDK结果Spring Boot 2.x跑不起来，报错全是UnsupportedClassVersionError，排查半天发现是JDK版本问题）；Maven 3.6.x；Node.js 16或18 LTS版本；Vue CLI 4.5.x或直接用Vite创建Vue 3项目；Spring Boot 2.7.x；MySQL 5.7或8.0。

这里有个很重要的建议：不要赶时髦用最新版本。Spring Boot 3.x和JDK 17的组合虽然新，但很多教程和第三方依赖还没有完全跟上，出了问题搜索引擎都难找到对应解决方案。毕设追求的是稳而不是新，大家时间有限，别在环境上磨掉一周。热词里提到"springboot版本太高"，说的就是这么个事。

5.2 Spring Boot项目初始化步骤

用IDEA创建Spring Boot项目的标准路径是：File → New → Project → Spring Initializr，选好JDK版本和Java版本，点击Next。这里有一个小坑：IDEA自带的Spring Initializr地址经常连不上，解决方案是把Server URL改成阿里云的镜像地址https://start.aliyun.com，创建速度快很多。依赖勾选时选Spring Web、MyBatis Framework（或Spring Data JPA，看个人习惯）、MySQL Driver、Lombok（强烈推荐，省掉一堆getter/setter）、Spring Security（如果做登录权限）就够用了。

项目创建完成后先别急着写代码，把application.yml配置好：数据源（数据库连接地址、用户名密码、时区设置serverTimezone=Asia/Shanghai）、MyBatis的mapper-locations路径、端口号（默认8080）、文件上传大小限制。配置好后先用一个简单的测试接口跑通"请求-数据源-响应"的链路，确认环境没有问题再开始写业务代码。这个习惯能避免后面越写越复杂时才发现基础环境有问题，到时候定位问题的成本就高了。

5.3 Vue项目初始化与前后端联调配置

前端项目的创建，建议用Vue CLI：vue create car-rental-frontend。创建时选择Vue 3，勾选Router和Axios；再安装Element Plus组件库：npm install element-plus（注意是Element Plus，不是Element UI，Element UI对应的是Vue 2）。有部分教程还在教Vue 2的写法，如果你选了Vue 3，照着Vue 2的教程写，代码会形态不对。这一块热词里"vue安装及环境配置""vue安装依赖"都是大家常遇到的问题，核心要点就是Node版本要匹配，不要用太老的Node。

联调阶段最大的坑是跨域（CORS）。前端跑在http://localhost:5173（Vite默认端口），后端跑在http://localhost:8080，直接从前端发请求必然跨域。有两个解决方案：方案一在后端配置CORS过滤器（@CrossOrigin或CorsFilter），方案二在前端Vite配置代理（在vite.config.js里配置server.proxy，把所有/api开头的请求代理到8080端口）。

我在项目里用的是方案二，因为方案二还能顺带解决一个开发问题：前端请求地址不需要写全路径，统一以/api开头，后端的Controller映射也就以/api为前缀，后期部署上线只需要改代理配置指向服务器IP，前端代码不用动。

6. 毕设全流程避坑实录：从开发到答辩的实战建议

6.1 后端开发阶段的血泪教训

第一坑：MyBatis的XML文件没打包进target目录。现象是启动不报错，但一调用数据库操作就报Invalid bound statement (not found)。原因是pom.xml里没有配置<resources>把src/main/java下的mapper.xml文件也打包进去。解决办法：在pom.xml里加一段资源配置，把xml文件包含进来，或者把XML文件放在src/main/resources/mapper/目录下。以后新建项目第一步就检查这个配置。

第二坑：Lombok依赖和IDEA的注解处理冲突。装好Lombok后编译正常但IDEA里找不到getter/setter方法。解决方式：IDEA设置里勾选Enable annotation processing。大概率是你的IDEA版本较新、默认没开。另外一个备选方案是直接用IDEA自带的Generate生成getter/setter，不用Lombok，但代码会显得冗余，我还是偏好Lombok。

第三坑：事务注解失效。Service层方法里如果自己catch了异常，Spring的事务代理就感知不到异常，事务不会回滚。正确做法是：不要吞异常，让RuntimeException抛出去，由全局异常处理器统一处理；或者手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()。下单时扣库存和创建订单必须在一个事务里，这一块出了问题，订单状态和车辆状态就对不上了。

6.2 前后端联调阶段的高频问题

前端最耗时间的通常是这种问题：接口返回的数据结构里某些字段为null，前端一渲染就报错。我们在后端加了保护：DTO字段使用基本类型包装类而不是原始类型（比如Integer而非int），同时接口统一返回一个Result<T>包装结构，包含code、message、data三个字段，前端根据code判断成功失败，data永远不回null。这算一个接口设计规范，写代码前就应该定好，不然联调时会反复调整。

另外Vue端的常见问题：表格数据用了{{ item.xxx }}但xxx字段不存在，控制台会报错但不影响页面渲染，调试时容易忽略。这里检查接口返回最直接的方式是打开F12看Network里对应的XHR请求，看Preview标签页里实际返回了什么，再对照前端代码排查。Vue开发调试强烈建议装Vue Devtools插件，查看组件状态和路由跳转会很省力。

6.3 论文、演示与答辩准备的独家建议

论文不是最后两周才开始写的。我的习惯是边开发边写：每完成一个模块（比如用户登录、车辆管理），就同步把论文的对应章节写了，代码是热乎的，逻辑讲得最清楚，后面只需要做整理论文全局和格式。开题报告里的研究现状部分，到写论文时回来改改就能直接用。

答辩演示有一条重要原则：提前准备一条完整的演示路径，从用户注册登录开始，到浏览车辆、下单、支付、商家接单、用户还车、评价，一条龙走完，中间不停顿。不要现场临时去点那些可能会出bug的功能，也不要每点一下就切回代码讲解。先跑完完整的业务闭环，再挑两三个亮点（比如JWT认证、订单状态机、车辆并发控制）切到代码讲解，时间控制在10分钟以内最理想。

老师提问环节，被问到答不上的问题怎么办？我的经验是诚实说"这块我主要参考了xx的实现思路，具体细节我还没有深入"，然后赶紧把话题引到你会的地方——"不过我在实现xx功能时遇到了xx问题，我是这样解决的"。老师往往不会追问到底，但你要让对方感受到这个项目确实是你自己动手做的。一定要对项目了如指掌：车辆状态字段有哪些、订单状态流转路径是什么、数据库表设计为什么这么分，这些基础问题能流利回答，答辩基本就稳了。

6.4 给学弟学妹的几条最实在的建议

第一，毕设是一个完整项目，不要只盯着代码。需求分析、数据库设计、接口设计文档，这些在论文里都要占篇幅的，开工前花一周时间把设计文档写好，后面开发效率能翻倍。第二，代码写完了不代表系统完成了，一定要自己完整走一遍所有业务流程，用不同角色账号都测试一遍，把流程走顺。第三，Git从第一天就用起来，哪怕只有你一个人开发。每天提交一次，出了bug可以回滚版本，写论文时还能通过commit记录回顾自己的开发过程，关键字段、版本变化、bug修复都是素材。

值得多说一句的是，如果时间允许，可以把项目部署到云服务器上，用公网IP或域名访问演示。答辩时老师可以直接用手机打开你的系统体验，这个效果比在自己电脑上跑强很多。部署本身不复杂：后端打成jar包用nohup java -jar后台运行，前端npm run build生成dist目录放到Nginx的html目录下，配置一个反向代理把/api请求转发到后端端口就行。如果遇到服务器公网无法访问的问题，九成是云服务商的安全组没放行对应端口，去控制台配置一下入方向规则就好——这个细节我身边有不少同学翻过车。

作为一个过来人，我的体会是：毕设选题太华丽没用，关键是你在做的过程中真的搞懂了几件事。选这个题目，你能够把Java基础、Spring Boot核心机制、Vue组件化开发、MySQL表设计、HTTP接口规范这些知识点串成一条线，这是四个多月专业课学习最好的收尾方式。按上面这套思路走下来，代码能写出来，论文能写满，答辩能讲清，这三件事同时做到，优秀毕设的基本盘也就稳了。