企业官网建设流程全解析

每年到做毕业设计的时候，总有一批人戴着痛苦面具到处找项目。SpringBoot+Vue 的旅游管理系统平台算是 Java Web 方向里最常被点到名的需求之一，原因很简单：业务场景大众化、功能模块好拆解、技术栈主流不冷门，再配上完整源码、SQL脚本和接口文档，基本就是冲着"开箱即用"来的。这套东西前前后后我断断续续整理过不少次，这次干脆把整个项目从结构设计到跑起来的完整链路都摊开说，覆盖前端 Vue 页面、后端 SpringBoot 接口、数据库表设计、本地部署启动和常见报错处理，无论是做毕设还是想拿一个全栈练手项目，这篇都能帮你少走弯路。

1. 项目全景：这套旅游系统到底解决了什么问题

1.1 功能模块清单

拿到一套源码，第一件事不是急着启动，而是先搞明白这个系统里到底有什么功能，对应的是哪些页面、哪些后端接口、哪些数据库表。这套标准套餐包含三个角色维度：游客、注册用户和管理员。

游客端可以浏览景点列表、查看景点详情、查看旅游线路和酒店信息，不需要登录也能看，目的是降低浏览门槛。注册用户的权限在游客之上，能登录、注册、修改个人信息，更关键的是能下单预订酒店或线路、对已完成的订单发表评论、在景点详情页收藏感兴趣的内容。管理员则是整套系统的核心操盘手，景点信息的增删改、线路和酒店的上下架、订单状态的管理、用户账号的禁用与恢复、统计数据的大盘浏览，全在前端单独的后台管理界面里完成。

功能模块拆开大致有：注册登录模块、景点信息模块、酒店信息模块、旅游线路模块、在线预订模块、订单管理模块、评论模块、收藏模块、用户管理模块、数据统计分析模块。一套标准的业务流程闭环就是：用户搜索景点或线路，查看详情后下单，管理员在后台审核或接单，用户游玩后回到系统写评论，管理员在统计页面看到订单量变化。

1.2 角色权限的设计思路

权限这块很多毕设项目做得比较随意，但"完整项目"的标签下，权限设计至少得有基本的区分度。前后端分离的项目里，前端路由守卫控制页面访问，后端接口通过 JWT 拦截器校验 token 并识别角色。管理员的接口会额外校验角色标识，非管理员访问管理接口直接返回 403。用户下单、改资料这些操作需要用户 token，游客只能访问公开查询接口。

权限表结构上，一般用用户表里一个 role 字段解决，而不是引入 RBAC 三张表。毕设体量这么做完全够用，引入 Spring Security 或 Shiro 反而增加学习成本。搞清楚源码里用的哪种方式，对你后续写论文或者答辩讲技术方案很重要。

1.3 这套源码的适用人群

这套东西最适合三类人：第一类是 Java Web 方向做毕设的学生，需要完整可运行、有文档、能讲清楚设计的项目；第二类是自学 SpringBoot+Vue 想做全栈项目的初级开发者，通过读完整源码能搞懂前后端数据交互的完整脉络；第三类是工作后想快速搭一套内部演示系统的开发者，把后端业务改吧改吧就能当原型用。

2. 技术选型的逻辑：SpringBoot+Vue 不是唯一方案，但为什么大家默认选它

2.1 前端为什么是 Vue 而不是 React

现在做 Java Web 毕设，前端选型几乎被 Vue 垄断了。原因不复杂：上手曲线平缓、中文资料覆盖率高、Element UI/Element Plus 组件库写后台管理页面效率极高。这套项目的前端用的是 Vue2 还是 Vue3，需要根据源码实际依赖决定，但你拿到手后一定要先确认版本，因为 Vue2 和 Vue3 的语法和生态差别不小，后面踩坑很多都跟版本混用有关。

如果源码用的 Vue2，对应的应该是 vue-router 3.x、vuex 3.x、Element UI；如果用的 Vue3，对应的是 vue-router 4.x、pinia 或 vuex 4.x、Element Plus。看 package.json 里的依赖版本就能快速判断。前端结构上，通常会有 views 目录放页面组件、router 目录放路由配置、api 目录放接口请求封装、store 或 vuex 目录放全局状态、utils 目录放 axios 实例和 token 工具函数。

2.2 后端为什么是 SpringBoot 而不是 SSM

SSM（Spring+SpringMVC+MyBatis）曾经是毕设标配，但 SpringBoot 把配置简化得太彻底了，内嵌 Tomcat、自动装配、starter 依赖机制，直接让 SSM 时代的 XML 配置地狱成为历史。这套后端大概率用的技术组合是：SpringBoot + MyBatis/MyBatis-Plus + MySQL + JWT + Knife4j/Swagger。

MyBatis-Plus 在毕设项目里几乎成了事实标准，因为内置的 BaseMapper 提供了单表 CRUD 的现成方法，不需要手写大量的 XML 映射文件。分页查询用 MyBatis-Plus 的分页插件，只需要配置一个拦截器就能用，对于景点列表、订单列表这种分页场景效率提升明显。JWT 则解决前后端分离下的会话管理问题，后端签发 token，前端存储并在请求头携带，无需依赖 Cookie。

2.3 前后端分离的架构意味着什么

项目标题里明确写了"前后端分离"，这意味着你需要同时启动后端服务和前端工程，它们通过 HTTP 接口通信。后端跑在 8080 之类端口，前端开发服务器默认跑在 8080 或 5173，前端请求通过 axios 指向后端的接口地址，跨域问题由后端配置 CorsFilter 或者前端 Vite 代理解决。

这个架构最直观的好处是前后端可以独立开发、独立部署，也更贴近企业真实项目形态。坏处是对新手来说排查问题变难了——前端报错可能是后端接口挂了，后端报错可能是参数没传对，需要掌握基本的接口调试能力。

3. 数据库设计：旅游数据的表结构拆分思路

3.1 核心数据表的作用与关系

旅游管理系统的数据模型比普通增删改查项目稍微丰富一点，核心表我列一下，你比对 SQL 脚本里的表结构就能对上：

• 用户表（user）：主键 id、用户名、密码（加密存储）、昵称、手机号、邮箱、头像、角色标识、创建时间、状态
• 景点表（scenic）：主键 id、景点名称、封面图、库存/余票、地理位置、简介、详细内容、评分、状态
• 酒店表（hotel）：主键 id、酒店名称、地址、星级、房型、价格、图片、简介、状态
• 线路表（route）：主键 id、线路名称、出发地、目的地、行程天数、价格、封面图、介绍、状态
• 订单表（orders）：主键 id、订单编号、用户id、商品类型（酒店/线路）、商品id、下单价格、状态、联系人、手机号、下单时间、支付时间
• 评论表（comment）：主键 id、用户id、商品类型、商品id、内容、评分、评论时间、状态
• 收藏表（favorite）：主键 id、用户id、商品类型、商品id、收藏时间

这些表之间的关联并不复杂，订单、评论、收藏都是多态的——同一个订单表既能存酒店订单又能存线路订单，靠"类型字段"区分。这种设计在毕设里非常常见，比拆成酒店订单表和线路订单表两张表更省事，但是写 SQL 关联查询时需要用类型字段去过滤，理解这个点对你看源码里的查询逻辑很有帮助。

3.2 表设计里容易被忽略的字段

看 SQL 脚本时别只顾着数表，有几类字段是你后续做毕设答辩时一定要能讲清楚的。第一个是状态字段，几乎所有业务表都有，景点和酒店的上下架状态、订单的待付款/已付款/已取消/已完成状态，这些状态流转撑起了业务逻辑。第二个是时间字段，create_time 和 update_time 在 MyBatis-Plus 里可以通过字段填充策略自动生成，不需要手动 set。第三个是逻辑删除标记，用 0 和 1 标记删除状态，避免物理删除导致的数据完整性问题。

3.3 SQL 脚本导入的完整步骤

拿到 SQL 脚本后，导入数据库的流程很固定，但很多人第一步就卡住。推荐用 Navicat 或者 MySQL Workbench，以 Navicat 为例：新建数据库，字符集选 utf8mb4（不是 utf8，utf8mb4 才能正确存 emoji 和生僻字），排序规则选 utf8mb4_general_ci 或 utf8mb4_unicode_ci，然后右键数据库选"运行 SQL 文件"，选定脚本后执行。

执行成功后你会看到数据库里出现上述所有表，注意观察每张表的字段和注释，SQL 脚本的质量决定了你的数据初始化是否顺利。一个常见问题是 MySQL 版本不一致：本地是 MySQL 8.0，但脚本是按 5.7 写的，或者反过来，可能出现排序规则不识别、存储引擎差异之类的报错。遇到这种情况优先改脚本里的建表语句，不要硬扛。

4. 后端接口文档的正确打开方式：从拿到文档到跑通联调

4.1 接口文档包含哪些内容

一套合格的接口文档至少包含四块：全局说明（基础地址、鉴权方式、统一响应格式）、业务接口列表（每个接口的请求方法、路径、参数、响应体）、数据字典（各字段含义）、错误码表（常见异常码和提示信息）。如果源码里集成了 Knife4j 或 Swagger，你启动后端后直接访问文档地址就能在网页上调试每一个接口，比拿 PDF 文档翻半天效率高得多。

常见的文档地址是：SpringBoot 启动后访问 http://localhost:8080/doc.html（Knife4j UI）或 http://localhost:8080/swagger-ui/index.html。这个地址在 application.yml 或者 your-project/doc 前缀配置里能调整。

4.2 核心接口的调用逻辑

以本项目里最核心的"下单"流程举例。前端点击"立即预订"按钮后，调用的接口路径一般是 POST /api/orders，请求体是 JSON，包含商品类型、商品ID、联系人、电话等信息。请求头必须带 Authorization 字段，值为 "Bearer " + token。后端收到请求后用 JWT 拦截器解析 token 拿到用户ID，然后执行订单创建。

游客浏览流程对应的接口是 GET /api/scenic/list、GET /api/scenic/{id} 这种只读接口，不需要 token。管理员操作景区信息的接口是 POST /api/admin/scenic、PUT /api/admin/scenic、DELETE /api/admin/scenic/{id}，这类接口后端会校验当前用户的 role 是不是 admin。

接口规范上，统一响应格式一般是 { "code": 200, "message": "success", "data": {...} }，前端 axios 拦截器里先判断 code 再决定走正常流程还是报错提示。你拿到源码后先看 axios 封装的 response 拦截器，就知道前端对接口返回的具体处理逻辑。

4.3 本地联调要准备哪些工具

不会接口联调，等于没拿到源码。推荐三个工具：Apifox（国产，接口调试和文档管理一体）、Postman（老牌、稳定）、以及浏览器直接访问后端接口地址。新手我建议直接用 Apifox，因为导入接口文档后可以一键调试，还能把接口整理成一个个目录。

联调时最常遇见的三个问题：第一是请求地址写错，前端写的路径和后端 @RequestMapping 的值拼不到一起，典型的对不上场景是忘记加 context-path 前缀；第二是请求头漏了 token，后端拦截器直接拦截，返回 401 或 403；第三是参数类型对不上，后端用 Integer 接收，前端传了字符串"1"，SpringMVC 通常会自动转换，但如果是日期类型、复杂对象类型就很容易报参数解析错误。

5. 前端核心页面与 Vue 组件化思路

5.1 页面清单与路由规划

前端部分按路径拆，大概是长这样：

• / 或 /index：首页，展示推荐景点、热门线路、搜索入口
• /scenic：景点列表页，支持按名称搜索、分页展示
• /scenic/:id：景点详情页，包含图片轮播、描述、评分、收藏按钮
• /hotel：酒店列表页，按地区、价格筛选
• /route：线路列表页，按天数、价格筛选
• /order：我的订单页，列出当前用户的所有订单，支持取消
• /login 和 /register：登录注册页
• /admin：后台管理首页，含数据统计图表
• /admin/scenic、/admin/hotel、/admin/route：各业务数据的管理页
• /admin/order：订单管理页
• /admin/user：用户管理页

路由配置里，需要登录才能访问的页面用路由守卫做拦截，代码逻辑通常是在 router.beforeEach 里检查 localStorage 里有没有 token，没有就跳 /login。需要管理员权限的路径则额外校验 store 里保存的角色信息，做一层双保险。

5.2 Axios 封装与 Token 管理

前后端分离项目里，axios 实例必须统一封装，否则每个页面都要写一遍 baseURL 和请求头，代码会非常冗余。正规做法是在 utils/request.js 里创建一个 axios 实例，设置 baseURL、超时时间，请求拦截器里从 localStorage 取 token 并设置到 header，响应拦截器里统一处理 401 跳登录和业务错误码弹消息。

Token 存哪里是个值得注意的细节。毕设项目普遍选择 localStorage，因为足够简单、刷新不丢失。但 localStorage 有 XSS 风险，生产项目会用 httpOnly Cookie 存 token。你答辩时能说清楚这两者的区别，反而是加分项。

5.3 组件复用带来的开发效率提升

从源码里能看到明显的组件化拆分思路。景点卡片、订单状态标签、分页组件、图片预览弹窗这些都是在多个页面复用的公共组件。新人看源码时最容易忽略的就是 components 目录里的公共组件，总觉得"页面代码都在 views 里"，实际上很多页面的核心展示逻辑都抽到了公共组件里。

比如首页推荐景点和景点列表页的景点卡片是同一个组件，只是数据来源不同。这种设计的好处是修改展示样式只需要改一处，全站生效。你在写项目文档或论文时，把"高复用组件的抽取策略"写进设计说明里，会比笼统写"采用前后端分离"更有说服力。

6. 本地部署与启动：从解压源码到完整运行的操作链

6.1 环境准备清单

动手启动前先把环境对齐，环境不一致是项目跑不起来的第一大原因。清单如下：

然后看后端 application.yml 或 application.properties 里的数据库连接配置：jdbc:mysql://localhost:3306/数据库名、账号、密码、端口、连接池配置。这里有一个高频踩坑点：如果本地 MySQL 是 8.0 版本，但 pom.xml 里的 mysql-connector-java 依赖是 5.x，会报连接错误或时区错误，需要把驱动版本升级到 8.x，并加上 serverTimezone=Asia/Shanghai 参数。

6.2 后端启动三步走

第一步，用 IDEA 打开后端项目文件夹，等待 Maven 自动下载依赖。如果等待时间太长，检查 IDEA 的 Maven 配置，仓库地址是不是设成了阿里云镜像，全局 settings.xml 里加：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

第二步，确认数据库连接配置无误后，导入 SQL 脚本，确保数据库名和配置里的 schema 一致。

第三步，找到主类，SpringBoot 项目一般长这样：

@SpringBootApplication public class TravelApplication { public static void main(String[] args) { SpringApplication.run(TravelApplication.class, args); } }

右键运行，看到类似 "Tomcat started on port(s): 8080" 的日志，说明后端启动成功。

6.3 前端启动三步走

第一步，打开前端项目文件夹，确认 package.json 里的依赖版本，特别是 vue 版本和 element-ui/element-plus 版本。

第二步，在终端执行 npm install。这一步是整个流程里最折磨人的环节，没有之一。卡顿、报错、超时都很常见。npm 官方源在国内速度很慢，先切换成淘宝 npm 镜像：

npm config set registry https://registry.npmmirror.com

执行完再 npm install，依赖下载速度会有质的提升。如果安装到一半失败，大概率是依赖版本冲突，留意命令行给出的 ERESOLVE 或 peer 依赖提示，可以通过 npm install --legacy-peer-deps 或者 npm install --force 解决。但注意：加这个参数只是绕过依赖冲突，如果你改动了版本，后续运行可能还会出现问题，所以要克制。

第三步，npm run serve 或 npm run dev 启动开发服务器。看到 "App running at" 提示后，浏览器访问，系统就能用了。前端和后端不同源，跨域配置要提前检查。看后端有没有配置 CorsFilter，或者前端 vite.config.js / vue.config.js 里是否配了代理。

以 Vite 为例，代理配置长这样：

server: { port: 3000, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

配置了代理之后，前端请求 /api/scenic/list 会被转发到后端 8080 端口的对应接口，本地开发就不存在跨域问题了。

6.4 端口冲突和配置修改

后端默认端口是 8080，前端开发服务器是 8080 或 5173 或 3000。如果你的 8080 甚至 80 端口被其他程序占用，后端会直接启动失败。确认方式是用命令行查端口占用：

在 Windows 上：

netstat -ano | findstr :8080

如果确实被占用，要么结束占用进程，要么在后端 application.yml 里将端口改成其他值。前端配置代理的时候，target 地址也要同步改成修改后的端口。

7. 跑通后的功能自查清单：别急着写论文，先把这些流程走一遍

7.1 注册登录与权限自查

系统跑起来后建议先过一遍完整业务链路，而不是看到首页就认为万事大吉。第一步直接注册一个新账号，看验证码/手机号校验是否生效，然后登录，看 token 是否写入 localStorage。退出登录后手动改一个假 token，访问需要登录的页面，确认前端路由守卫会拦截并跳回登录页。

7.2 下单支付退款闭环

日记用户登录后选择一条线路，进入详情页，点击"立即预订"，填写联系人和联系电话，提交订单。到订单列表页确认新订单出现，取消这笔订单，确认状态变为已取消。管理员登录后台，查看所有订单，确认状态同步正确。这个流程能走通，基本说明后端订单模块、前端页面、数据库写入这三个链路都是通的。

7.3 后台管理 CRUD 与统计图表

后台登录管理员账号，分别测试景点、酒店、线路的"新增-编辑-删除-查询"流程。新增一个景点后在前台首页或列表页刷新，确认数据实时展示。然后去统计页面看图表是否正常渲染。很多项目的图表组件不加载是因为 ECharts 依赖没正确引入，或者初始化代码在 DOM 未渲染完成时执行，遇到图表空白时优先排查这两个点。

8. 高频报错的完整排查链路

8.1 数据库连接失败：报错信息不会说谎

最常见的报错是 Communications link failure 或 Access denied for user。前者最常见的原因是 MySQL 服务没启动、连接配置里的 URL 写错、或者是驱动的时区参数缺失。后者的原因是账号密码不对或用户权限不足。排查顺序是：确认 MySQL 服务运行中，确认本地可以通过命令行连上数据库，确认 application.yml 里的账号密码、库名均一致。很多人栽在最简单的地方——数据库密码里带了特殊字符，比如 @ 号，直接用在 yml 配置里可能导致连接串解析异常，这种情况需要对特殊字符做转义。

8.2 前端报错 Uncaught SyntaxError: Unexpected token '<'

这个报错极具迷惑性，表面看着是前端语法错误，实际上通常是前端把后端启动失败时返回的错误页当成 JS 文件加载了。为什么会这样？因为 index.html 里引用了 /js/chunk.js，但后端端口根本没服务，或者代理指向了错误的后端地址，返回的是一个 HTML 错误页面，浏览器拿到 HTML 后开始解析 JS 就报了这个错。

排查思路：先看后端是否正常运行，再看 Vite/Webpack 代理配置是否指向正确端口，最后在浏览器 Network 面板里看出现该错误的 JS 文件实际响应头 Content-Type 是否为 application/javascript，如果不是，就是代理或静态资源路径的问题。

8.3 分页查询不生效：MyBatis-Plus 配置缺失

如果你在源码里看到用了 MyBatis-Plus 的 selectPage 方法，但查询结果里 total 是 0 或者所有数据一次性查出来了，那大概率是分页插件没有注册。MyBatis-Plus 3.x 之后需要单独配置：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

没有这段配置，Page 参数不会自动拼装 LIMIT 语句，分页功能就形同虚设。

8.4 前端端口和打包部署的常见理解误区

很多第一次接触前端开发的读者会混淆"流程启动"和"生产打包"。npm run serve 启动的是开发服务器，改了代码浏览器会自动刷新，适合开发调试。毕设演示时用开发模式完全没问题，但如果要部署到服务器，需要先执行 npm run build，生成 dist 目录的静态文件，再用 Nginx 或其他服务器托管 dist 目录并配置反向代理到后端接口。

如果演示现场换了电脑，环境变量没配或者依赖没装，最容易翻车的就是前端。稳妥的做法是确保所有运行依赖都在，npm run build 产物尽早验证，不要到了答辩前一天才改打包配置。

8.5 字体和图标渲染不出来

另一种常见但不太被人关注的错误是，后台管理界面登录页面或布局组件的字体图标显示为方块。Element UI/Element Plus 的字体文件是在 npm 包里，正常情况下打包时会自动拷贝。项目里的静态资源 base URL 配置不对，比如 vite 里 base 配了子路径但访问时没加这个前缀，就会导致字体文件 404。排查方式同样是 Network 面板看资源请求路径与实际资源位置是否一致。

9. 从拿到源码到完成毕设的时间规划

9.1 各阶段的时间分配参考

完整项目的消化周期建议控制在三到五周，别贪快。第一周：环境搭建 + 数据库导入 + 跑通前后端 + 通读核心业务代码，目标是让系统在你自己电脑上稳定运行。第二周：梳理业务流程，画出核心业务的功能流程图和数据流图，结合接口文档整理出后端所有接口清单。第三周：根据接口清单对应前端页面，搞懂每个页面调用了哪些接口、数据如何流转，同时开始写论文的开题背景和需求分析章节。第四到五周：重点写系统设计和实现章节，收集测试截图、核心代码片段，准备答辩 PPT。

9.2 毕设文档与源码对齐的技巧

与其花时间死记源码，不如把文档和代码做成对照关系。比如论文里写"系统采用 JWT 进行身份认证"，你就去源码里找到 JWT 工具类，搞清楚 token 的生成、过期时间设置、登录时如何触发签发。论文里写"采用 MyBatis-Plus 简化数据访问层开发"，你就找一条实际的 selectPage 调用记录。真正做到文档代码一一对应，答辩的时候被问到的每个点你都能从代码里指出来，这是坦然面对评委的关键。

9.3 答辩时核心讲解思路

答辩讲解的侧重点不是报流水账，而是讲清楚三件事：系统解决了什么问题、你在实现过程中做出过哪些关键设计决策、遇到哪些坑怎么解决的。比如"为什么用 JWT 而不是 Session"，可以答出 Session 在集群环境下需要共享存储、前后端分离后 Cookie 跨域能力弱，JWT 天然适合分布式的无状态场景。"为什么用逻辑删除而不是物理删除"，可以答出历史订单数据需要留存审计，物理删除会破坏数据完整性。这类设计问题的回答质量，能把你的项目从"抄代码"的嫌疑中解救出来。

10. 源码阅读顺序与二次开发建议

10.1 从哪开始读源码效率最高

不建议从 main 方法开始逐行读，效率太低。正确的顺序：先看数据库表结构，建立数据模型的概念；再看后端 controller 层，了解对外暴露了哪些接口；然后看 service 层，理解业务逻辑；最后看 mapper 层，确认 SQL 和表结构能否对上。后端代码结构上常见四层：controller、service、mapper、entity，目录清晰的项目一眼就能识别。

前端源码阅读顺序：先看 router 配置，了解有哪些页面路径；再看 api 目录，了解每个页面调用哪些接口；然后挑一个代表性页面从头读到尾，比如景点列表页，搞懂从 axios 请求到数据渲染的完整链路；最后看 store，确认全局状态管理了哪些数据。

10.2 可以在源码基础上做哪些扩展

如果不想论文撞车，可以做适度二次开发。推荐几个成本低、效果明显的扩展方向：增加个人中心页面，把头像上传、密码修改、我的收藏整合到一起；增加多条件搜索，比如按价格区间、按评分排序；增加轮播图管理功能，让首页的 Banner 可以在后台动态配置；导出功能，把订单列表导出为 Excel 可以作为技术亮点写入论文。扩展功能不需要改核心架构，只在现有模块上加增量逻辑，适合在毕设冲刺阶段快速落地。

10.3 发布前要做好的三项检查

本地验证通过后，不要直接打包。先检查数据库脚本是否有初始化数据，页面上的展示内容不至于是一片空白；再检查默认管理员账号是否可用，如果邮箱验证码、手机验证码依赖第三方服务，需要提前确认相关配置；最后确认项目文档里写的运行步骤和设备是同一套环境，避免换电脑运行时报环境错误。

我个人在实际操作中的体会是，这类完整项目给你最大的价值不是替你省掉思考，而是提供了一个可以对照的"正确答案"，让你在遇到问题时有迹可循。真正把它研究明白的关键在于自己动手把项目拆开再拼回去——今天改一个字段试试效果，明天换一个组件看看机制，等你能在原项目的基础上做改动并且跑得比原来更好时，这场毕设的训练目标才算真正完成。最后想分享的小建议是打包部署前务必把 npm run build 的产物在本地起一个 Nginx 服务验证一次，不然答辩现场开场三分钟就翻车。