企业官网建设流程全解析

前阵子有个学弟找我聊毕业设计选题，他说想做个网页类的系统，但不想再做那种千篇一律的图书管理、学生管理系统。我听到他想做旅游相关的方向，第一反应是认同——旅游网站场景贴近生活，数据模型有一定复杂度，前端页面能做得漂亮，后端逻辑也够丰富，不管是做毕设还是写进简历，都有足够的内容可以讲。他后来定下的题目，就是SpringBoot+Vue+MySQL搭建的“七彩云南文化旅游网站平台”。

这个题目我帮他从头到尾梳理过一遍，包括前期的技术选型、数据库设计、后端接口划分、前端页面结构、论文怎么写、部署时踩过哪些坑，基本都摸过一遍。所以这篇博客想把这些内容都整理出来，给正在做同类毕业设计、或者想自己从零搭一个完整前后端分离项目的同学参考。内容偏实战，不绕弯子，全程都是可以直接复用的思路和代码层面的方案。

1. 项目整体拆解：这到底是一个什么样的毕设项目

1.1 题目背后的核心需求

先说人话：这个系统就是一个以展示云南旅游信息为主、附带用户交互功能的网站平台。它不是一个单纯展示静态页面的官网，也不是一个复杂的电商系统，而是介于两者之间的一个典型信息管理加用户互动平台。

为什么这个题目适合做毕设？原因有三个：

第一，数据模型清晰。旅游网站的核心数据无非就是景点、旅游线路、酒店、攻略文章、用户评论这几类，每个实体的字段和关联关系都非常直观，不会像电商系统那样要处理购物车、库存、促销、支付分账那一大堆复杂逻辑。

第二，业务场景完整。既有游客角色的浏览、搜索、评论、收藏，也有管理员后端的景点管理、线路管理、用户管理、评论审核，天然形成一套“前台展示+后台管理”的双端结构，正好覆盖了毕业设计常见的功能要求。

第三，技术栈典型。后端SpringBoot负责业务接口，前端Vue负责页面渲染，MySQL存数据，这三样组合是当前Web开发的主流搭配，答辩时不会被问到“为什么不用某某技术”这种难堪的问题。

1.2 系统角色与功能边界

我在拆解这个项目时，通常会把角色分成三类：

• 游客（未登录用户）：可以浏览首页、查看景点列表和详情、搜索景点、查看旅游线路和攻略文章，但无法评论和收藏。
• 注册用户（登录后）：在游客权限基础上，增加发表评论、收藏景点、查看个人收藏列表、修改个人信息等功能。
• 管理员：负责后台系统的全部管理操作，包括景点信息的新增修改删除上下架、线路管理、攻略文章发布、用户管理、评论审核。

这个角色划分非常经典，也很有讲究。很多同学一开始会犯一个错误，就是把所有功能都堆在同一个页面或者同一个角色上，看起来功能倒是不少，但答辩时老师一句“你的权限控制是怎么做的？”就把你问住了。把角色拆清楚，权限控制的实现才有说头。

另外还要在前期明确一个边界：这个系统要不要做支付功能？要不要做真实的订单交易？我的建议是不做，或者只做“线路预约”级别的模拟订单。理由很简单，真实支付涉及到第三方接口、回调、退款这些复杂流程，对毕设来说属于“高风险、低回报”的功能，写起来耗时，答辩时也不一定加分。反过来，如果做一个“线路报名”功能，只需要用户提交意向信息、管理员后台确认，这样既有了业务闭环，又避开了支付复杂度，性价比高很多。

1.3 交付物清单的理解：源码、数据库、论文、部署文档

题目里提到的“源码+数据库+论文+部署文档”，其实就是这个项目的完整交付物。很多同学不明白为什么毕设要交一整套东西，这里我多解释几句：

• 源码：评委老师要看你真的把系统写出来了，不是画个草图而已。源码要求能编译、能运行，结构清晰，注释适量。
• 数据库：光有源码没有数据表，系统就是一个空壳。数据库SQL文件里要包含建表语句、初始测试数据，最好连管理员账号一起准备好。
• 论文：这是毕业设计的文字证明，描述你做了哪些工作、解决了什么问题、系统怎么设计怎么实现。
• 部署文档：用来证明你的系统不是只能在你自己电脑上跑，换一台机器按照文档步骤也能跑起来。这一点在远程答辩或演示环节尤其重要。

所以这个题目表面上是一个编程任务，实际上是一整套“工程交付”流程。在后面几节里，我会按这套交付物的顺序把关键技术点全部展开。

2. 技术选型与架构分析：为什么是SpringBoot+Vue+MySQL

2.1 技术栈选型的真实逻辑

先说结论：SpringBoot + Vue + MySQL，不是因为这个组合性能最强，而是因为它最适合“一个人从零开始完成一个全栈项目”的场景。

后端用SpringBoot，核心优势在于“约定大于配置”。早期用SSH那些框架，光配置文件就能写好几页，而现在SpringBoot的项目结构几乎是固定模板：启动类放根包下，Controller、Service、Mapper分层写，配置写在application.yml里。对没有太多项目经验的同学来说，这种“少思考、多搬砖”的体验特别重要，能把精力集中在业务逻辑上，而不是浪费在环境配置上。

前端用Vue，理由同样务实。Vue的上手曲线比React平缓，单文件组件结构直观，一套模板语法就能覆盖常用场景。再加上Element UI或者类似组件库，后台管理页面基本是“套模板 + 改表单字段”的节奏，开发效率非常可观。

MySQL则是小型Web系统的稳妥选择。它是关系型数据库，表结构清晰，团队里大家基本都学过SQL，出了问题也好排查。虽然PostgreSQL和MongoDB各有优势，但毕设项目用MySQL最不容易出幺蛾子，后期写论文也最顺手。

2.2 前后端分离与单体架构的取舍

这个项目我强烈建议做前后端分离，因为它更贴近当前企业的真实开发模式。前后端分离的意思，简单说就是后端只提供数据接口，前端负责渲染页面，两者通过JSON格式的数据进行通信。开发时前端可以单独启动一个开发服务器，后端单独跑在另一个端口，部署时再把前端打包后的静态文件交给Nginx托管，或者直接把前端打好的dist目录放到后端项目的static目录里。

前后端分离的好处有很多，比如职责清晰、并行开发、扩展方便。但对一个毕设来说，最重要的好处其实是“看起来更专业”。你可以在答辩时把项目结构图亮出来，说“前端是独立工程，后端是另一个独立工程，中间通过RESTful接口通信”，老师一听就知道你理解现代Web开发的套路。

不过这里也要提醒一句：前后端分离在开发阶段会遇到跨域问题。所谓跨域，就是前端的域名或端口和后端的域名或端口不一致时，浏览器会拦截请求。解决办法有两种：

• 后端加CORS全局配置；
• 前端用开发代理（Vue CLI中配置proxy）把请求转发到后端端口。

我在实际开发中更推荐第二种方式，因为它对代码没有侵入性，只在开发环境生效，部署后由同一个服务器提供服务，不存在跨域问题。后端CORS配置也可以写，但要注意不要直接允许所有来源（"*"），否则上线后会有安全隐患，也会被答辩老师挑毛病。

2.3 项目目录结构的组织思路

一个好的目录结构能让你的代码看起来“很专业”，也会让你自己开发时少走弯路。我的推荐结构如下：

后端（SpringBoot工程）：

src/main/java/com/example/travel/ ├── TravelApplication.java ├── config/ // 配置类，如跨域配置、拦截器配置 ├── controller/ // 接口层 ├── service/ // 业务逻辑层 ├── mapper/ // 数据库操作层 ├── entity/ // 实体类 ├── common/ // 公共类：统一返回结果、异常处理等 └── utils/ // 工具类：JWT工具、文件上传等

前端（Vue工程）：

src/ ├── api/ // 接口请求封装 ├── assets/ // 静态资源 ├── components/ // 公共组件 ├── router/ // 路由配置 ├── store/ // Vuex状态管理 ├── views/ // 页面文件 ├── App.vue └── main.js

特别说一下后端common目录里的“统一返回结果类”，这是很多项目容易忽略但非常关键的组件。它的作用是把所有接口的返回格式统一成{code, message, data}这种结构。好处有两个：一是前端不需要为每个接口单独处理返回数据的格式；二是出现异常时，前端能统一捕获并提示。这个类写起来不复杂，但能让你的整个项目在代码质量和答辩观感上提升一个档次。

3. 数据库设计核心细节：旅游网站的数据模型怎么建

3.1 核心数据表与字段设计

一个旅游网站平台，数据表的数量通常在8到12张左右，太少说明功能设计不够完整，太多又会增加开发工作量。我列一个最常用的表结构方案：

• 用户表（user）：用户ID、用户名、密码（加密存储）、昵称、手机号、头像、性别、角色（普通用户/管理员）、创建时间。
• 景点表（scenic_spot）：景点ID、名称、简介、详细描述、封面图片、所在城市、门票价格、开放时间、热度值、状态（上架/下架）、创建时间。
• 旅游线路表（travel_line）：线路ID、线路名称、途经景点（可以是多个景点ID拼接的字符串，也可以用中间表）、线路天数、价格、行程简介、封面图、状态。
• 酒店表（hotel）：酒店ID、名称、地址、星级、参考价格、图片、简介、状态。
• 攻略文章表（strategy）：文章ID、标题、作者ID、封面图、内容（长文本）、发布时间、浏览量、状态。
• 评论表（comment）：评论ID、用户ID、关联对象类型（景点/线路/攻略）、关联对象ID、评论内容、评分、状态（待审核/已通过/已屏蔽）、创建时间。
• 收藏表（favorite）：收藏ID、用户ID、关联对象类型、关联对象ID、收藏时间。
• 公告表（notice）：公告ID、标题、内容、发布时间、状态。

关于表之间的关联关系，有一个决策点要做：景点和旅游线路是“多对多”的关系，一条线路会包含多个景点，一个景点也可能出现在多条线路里。处理方式有两种：一是简单粗暴地在线路表里存“景点ID集合”的字符串；二是建立一张线路-景点中间表。为了保持数据库规范化，为了让论文里的E-R图更完整，我建议用中间表，多花十分钟建表，后面写论文时能多写一整节。

3.2 为什么要这样设计：主键、索引与字段类型

主键方面，一律使用自增ID或者雪花ID，不要用业务字段做主键。比如景点名称可能重复，而且一旦需要修改就很麻烦。这里我推荐使用自增ID，简单可靠，对MySQL性能也友好。不用UUID做主键的原因在于：UUID是随机字符串，在InnoDB引擎下用作主键会导致索引树频繁分裂，写入性能有损耗；同时UUID没有业务含义，查询也不方便。

索引设计上，有几个字段一定要加索引：

• 景点表的“城市”字段，因为用户经常按城市筛选旅游景点；
• 评论表的“关联对象ID”，因为详情页要按景点ID查评论列表；
• 用户的“用户名”字段，因为登录时要按用户名查找用户。

关于景点价格和线路价格，这里有一个容易踩的坑：价格不要用float或double类型，而应该用decimal类型。float和double是浮点数，在计算时会丢失精度，比如19.99存进去再读出来可能是19.989999。decimal是固定精度的小数，专门为金额这种场景设计。这个细节如果被答辩老师问到，答得上来会非常加分。

图片字段只用存图片相对路径或URL，千万不要把图片转成Base64塞进数据库，那样会让数据库文件极速膨胀，页面加载也会卡死。

3.3 测试数据的准备技巧

数据库设计做完以后，还有一个看起来不起眼、实际很重要的环节：准备初始测试数据。很多人随便插三五条记录就完事，结果做前端页面时发现列表太短，看不出分页效果，搜索功能也没有充分的测试对象。

我建议至少准备：

• 用户表里放2个管理员、10个左右普通用户；
• 景点表放20到30条记录，覆盖云南多个城市，比如昆明、大理、丽江、西双版纳、香格里拉，注意名称不要用真实景点名，可以用“某古城景区”“某高原湖泊”这类替代；
• 线路表放5到8条线路，每条线路关联2到4个景点；
• 评论表放几十条，覆盖不同用户和不同景点；
• 攻略文章至少5篇。

这样做的目的，不仅是为了开发和测试方便，更是为了给论文里的“系统功能展示”截图环节提供素材。演示时页面上有丰富数据，整体效果和说服力远胜于几张空表。

4. 后端功能模块实现要点：从登录鉴权到核心业务闭环

4.1 登录鉴权：JWT方案与安全注意事项

在一个前后端分离的项目里，登录状态的保持是绕不开的问题。传统方案用Session，但前后端分离场景下，Session处理跨域和集群环境都比较麻烦，所以目前的主流方案是JWT（JSON Web Token）。

JWT的逻辑可以理解为：用户登录成功后，后端生成一个带着用户信息的加密令牌返回给前端，前端把它存在本地存储里，之后每次请求都在HTTP头里带上这个令牌，后端验证令牌有效就认为用户已登录。

具体实现时，建议用现成工具类来生成和解析JWT，不要自己手写加密算法。需要前端注意的关键点是：请求拦截器里统一从localStorage或sessionStorage取Token并加到请求头上；响应拦截器里如果收到401状态码，就统一跳转到登录页并清除本地Token。

这里有一个安全细节必须提醒：JWT令牌里不要存放明文密码，也不要存放过多的敏感信息，一般放用户ID、用户名和角色就足够了。另外JWT要设置过期时间，比如24小时，过期后要求用户重新登录。虽然过期时间设置太短会影响用户体验，但设置过长又会增加被盗用后的风险，折中选择24小时比较合理。

接口权限控制方面，登录接口、注册接口、景点列表和详情接口放行；提交评论、收藏、以及后端所有管理接口都必须验证身份和管理员权限。最简单的做法是写一个拦截器，拦截所有请求，放行白名单URL，其余接口通过解析JWT来判断是否有权限。

4.2 景点模块：列表分页、条件搜索、详情展示

景点模块是整个系统最核心的业务模块，实现了它，旅游线路、酒店这些模块基本上就能照葫芦画瓢。

列表接口的设计要考虑分页和搜索。分页参数建议用pageNum（页码）和pageSize（每页条数），用MyBatis的PageHelper插件或者手写SQL的LIMIT都能实现。搜索条件通常包括：景点名称模糊搜索、城市筛选、价格区间筛选。SQL层面用动态SQL拼条件，在Mapper的XML里用<if>标签依次判断每个字段是否为空，这是很常规的写法，不难但必须熟练掌握。

详情接口要返回的信息比列表多，除了景点基本信息外，还包括评论列表、相关线路推荐、热度值信息。这里要注意区分：详情接口一次返回所有评论和推荐线路，会导致接口响应时间变长，前端首屏体验也会变差。所以更好的做法是详情接口只返回景点基本信息，评论和推荐线路单独提供子接口，前端在页面加载时并行请求。这个“接口拆分”的思路在答辩时说出来也很加分，说明你考虑到了接口性能问题。

景点“热度”的设计可以简单做：每个景点表加一个hot_value字段，浏览量+1时可以顺便让这个字段递增，列表接口按热度排序。这样做虽然简单，但已经能支撑“热门景点推荐”这个功能点，写论文时也可以作为“交互功能”的一点内容。

4.3 评论与收藏：简单功能里的权限控制

评论和收藏是典型的“登录后才能操作”的功能，正好可以用来实践权限控制。

提交评论的后端逻辑要注意三点：

第一，校验用户是否登录，这可以通过解析JWT里的用户ID实现； 第二，校验评论内容不能为空、不能过长，防止脏数据进库； 第三，评论默认状态设为“待审核”，管理员审核通过后才在前台显示。

收藏功能的核心是唯一性校验，防止同一用户对同一景点反复收藏。可以在收藏表的用户ID和关联对象ID上建立联合唯一索引，这样数据库层面就能直接拦截重复收藏，不需要在代码里先查询再判断。这一招简单有效，也体现了对数据库约束的理解。

4.4 文件上传：图片管理的简单方案

旅游网站涉及景点封面图、攻略文章图片、用户头像，文件上传是必备功能。

实现方案主要有两种：

• 上传到本地服务器指定目录，数据库存相对路径；
• 上传到云存储服务。

毕设项目推荐用本地存储方案。后端写一个上传接口，接收MultipartFile，保存到项目配置的上传目录，返回可访问的URL路径。但要注意几点：

• 要校验文件类型，只允许jpg、png等图片格式，防止上传恶意文件；
• 要限制文件大小，比如单张图片不超过5MB，SpringBoot中可以在配置里设置最大上传大小；
• 文件名不能直接用用户上传的原文件名，要用时间戳加随机字符串重命名，否则不同用户上传同名文件会产生覆盖问题，也会出现中文文件名在URL访问时的乱码问题。

部署到服务器时，上传目录最好不要放在项目源码目录内，而是放在服务器上的一个独立目录，比如/data/travel/upload，避免重新打包部署时覆盖掉已上传的图片。这个细节处理得好，部署后就不会出现“我明明传了图片，重新部署后全没了”的尴尬局面。

4.5 统一异常处理：让接口报错不再裸奔

很多初学者写的后端接口，一旦代码抛出异常，前端收到的是默认的500错误页或一堆看不懂的堆栈信息，这对用户体验和项目质量来说都是灾难。正确做法是写一个全局异常处理器，用@RestControllerAdvice注解捕获异常，统一包装成{code, message, data}结构返回。

实际的处理逻辑可以这样设计：

• 业务逻辑里主动抛出的异常（比如“登录名或密码错误”“该景点不存在”）统一返回200状态码、业务错误码和提示信息；
• 参数校验失败的异常返回参数错误码；
• 未捕获的运行时异常返回500状态码和“服务器繁忙”这类兜底提示，同时把详细异常信息记录到日志里，方便排查。

这样一来，前端拿到的永远是结构一致的JSON，代码里的message字段可以直接用来提示用户，后端也不会把内部细节暴露给外部。

4.6 事务处理：线路推荐和批量操作的数据一致性

如果你实现了“线路删除”或“批量上下架”功能，就要考虑事务问题。比如说，删除一条旅游线路时，除了删除线路本身，还要一并把线路关联的资源和它的收藏记录清理掉。如果不加事务，可能会出现“线路没了但关联数据还残留”的脏数据。

SpringBoot里开启事务很简单，在Service方法上加@Transactional注解即可。但要理解，事务的意义在于：要么所有操作都成功，要么所有操作都回滚，绝不能出现“做了一半”的状态。

这里顺便分享一个我踩过的坑：在同一个类里，一个Service方法调用另一个方法，@Transactional事务注解可能会失效。因为Spring的事务是基于AOP代理实现的，而同类内部调用走的是内部方法，不经过代理对象。解决办法是把需要事务的方法拆分到不同的类，或者通过注入自身的代理对象来调用。这个问题在答辩时被问到过，能答出原因和解决办法会很加分。

5. 前端Vue功能与交互实现：从页面骨架到接口对接

5.1 前端路由与页面结构规划

前端页面规划要结合角色权限来设计。我按照实际开发路径，整理出一个典型的页面清单：

用户端：首页（轮播图+热门景点+推荐线路）、景点列表页、景点详情页、线路列表页、线路详情页、攻略文章列表页、文章详情页、个人中心（我的收藏、我的评论、个人信息修改）、登录页、注册页。

管理端：管理员登录页（可以和用户登录页共用，根据角色跳转不同首页）、数据概览仪表盘、景点管理、线路管理、酒店管理、攻略管理、评论管理、用户管理、公告管理。

这里有一个很关键的交互设计：用户端和管理端是两个不同的首页布局。用户端更偏“门户网站风格”，有导航栏、轮播图、卡片列表；管理端则是典型的后台布局，左侧菜单、右侧内容区。两类页面模式不同，正好能体现你对Vue组件化和路由嵌套的理解。

5.2 请求封装与路由守卫：前端项目的“基础设施”

写Vue项目时，我不建议每个页面都直接通过axios.get发送请求，那样代码会非常冗余、难以维护。规范做法是提前写好统一的基础设施：

• api/request.js：创建一个axios实例，设置基础路径和超时时间，添加请求拦截器和响应拦截器。
• api/module.js：按业务模块封装接口函数，比如getScenicList(params)、login(data)，页面里只调用函数，不直接碰axios。
• router/index.js：配置路由表，并添加全局前置守卫，判断用户是否登录、页面是否需要登录权限、管理端页面是否只有管理员能访问。

路由守卫是前端权限控制的核心。我举一个典型写法：在meta字段里标记requiresAuth: true或requiresAdmin: true，守卫里检查本地存储中的Token和用户角色，不满足条件就跳转到登录页或404页。

顺带说一句，前端“登录后状态”的保存不要只用localStorage，建议同时配一个Vuex的state来存用户信息。这样做的原因是：localStorage负责持久化，Vuex负责页面组件之间的响应式数据共享，比如登录后右上角立刻显示用户名，这个更新如果只靠localStorage是不会自动触发视图刷新的，而Vuex就可以做到。

5.3 核心页面实现要点

首页是给评委和老师看的“第一印象”，值得多花心思。建议结构是：顶部导航栏 + 轮播图 + 热门景点推荐（卡片式横向滚动） + 精选旅游线路 + 最新攻略文章。这些数据都来自后端接口，不要写死在前端。

景点列表页的重点是筛选栏和分页。筛选栏包括城市下拉框、名称搜索框、价格区间输入框，点击查询后重置页码并请求接口。需要注意城市下拉框的数据源：可以写死一份云南主要城市的数组在前端，也可以从后端接口读取景点城市去重后的列表。后者更规范，因为城市信息也属于动态数据。

景点详情页要处理的信息层次比较多：基本信息、大图展示、评论区域、收藏按钮、相关推荐。三个数据接口并行加载，页面加载时先展示骨架屏，数据回来后再渲染。“收藏”按钮要做状态判断：如果已收藏，显示“已收藏”且不可点击或点击后取消收藏。

个人中心页实现相对简单，就是调用“我的收藏列表”和“我的评论列表”接口，用tab页切换展示。信息修改功能要区分：昵称、头像可以修改，用户名和手机号视设计而定，密码修改需要验证旧密码。

5.4 前端常见交互问题与解决思路

前端开发中几个高频问题，我提前列出来：

• 路由跳转后页面滚动位置不重置：在路由配置里添加scrollBehavior，返回顶部。
• 图片加载失败显示裂图：给img加onerror占位图处理，或者统一用组件封装。
• Token过期后页面不提示直接卡死：响应拦截器里捕获401后统一跳转登录页并给出提示。
• 管理端表单验证规则缺失：使用Element UI的rules校验，比如必填、长度限制、URL格式。
• 搜索条件与分页参数冲突：修改筛选条件时必须把页码重置为1，否则可能停留在超出范围的页码上。

这些问题虽然细碎，但处理好了会显著提升使用体验，也是论文和演示中说得出口的“实施细节”。

6. 论文写作、部署上线与常见问题排查

6.1 毕业设计论文的章节结构建议

论文是这个项目交付物里容易被轻视、但对最终成绩很关键的部分。我推荐按以下章节结构来写：

• 第一章 绪论：背景与意义、国内外研究现状、论文主要工作与结构安排。
• 第二章 相关技术介绍：SpringBoot、Vue、MySQL、前后端分离、JWT等。
• 第三章 需求分析：功能性需求、非功能性需求、用例图与用例描述。
• 第四章 系统设计：总体架构、功能模块设计、数据库设计（E-R图、表结构说明）。
• 第五章 系统实现：按照功能模块，逐一给出页面截图与核心代码片段。
• 第六章 系统测试：测试环境、功能测试用例表、测试结果分析。
• 第七章 总结与展望：已完成工作、存在的不足、后续改进方向。

写论文的最大技巧是“按开发产物反推文档”：先有系统功能和代码，再根据实际实现了什么来组织文字，不要凭空想象功能来写。比如第五章的系统实现，每个小节就对应一个已经跑通的功能模块，截图和代码直接从系统里取，写得又快又真实。

6.2 部署前需要做好的几件事

部署环节是不少同学翻车的地方，很多系统在自己电脑上跑得好好的，换机器或上服务器后就出各种问题。我总结部署前必须做好的准备：

第一，把配置外置化。application.yml里的数据库地址、账号、密码，不要写成localhost和本机测试账号，而应该改成部署环境的真实值。最稳妥的做法是用配置项区分开发和生产环境，通过spring.profiles.active切换。

第二，数据库脚本要完整。除了建表语句，测试数据、初始管理员账号都要一起导出成SQL文件。导入时注意编码问题，建议统一使用UTF-8编码，不然打开页面全是乱码。

第三，前端工程要构建。运行npm run build把Vue工程打包成静态文件，生成的dist目录里的文件才是真正可部署的产物。不要在上线后直接把源码放到服务器上跑开发服务器，那样既不专业也不稳定。

第四，确认端口和防火墙。后端默认端口8080，前端构建后可以用Nginx代理到80端口，Nginx配置里把前端和后端的请求路径区分开，比如/api开头转发到后端端口，其余请求直接指向前端静态文件。

6.3 部署实操流程：以一台全新服务器为例

在部署文档里，我建议把操作步骤写得非常具体，因为很可能按文档执行的人不是你自己。一个基础的部署流程大致如下：

• 安装基础环境：JDK、MySQL、Nginx，按版本要求装好，配置好环境变量和开机自启。
• 导入数据库：用命令行或图形工具执行SQL文件，创建数据库和账号，分配权限。
• 上传后端代码：把SpringBoot项目用Maven打成JAR包，执行java -jar启动，注意指定生产环境的配置参数。
• 上传前端静态文件：把dist目录里的文件放到Nginx的网站根目录，配置Nginx的server块。
• 开放访问：浏览器访问服务器IP或域名，测试登录、浏览、管理后台等功能。

这里要额外提一个容易被忽略的问题：服务器上MySQL的时区设置，如果默认时区不对，Java程序连接时会报“serverTimezone”错误。可以在连接参数里加serverTimezone=Asia/Shanghai，或者在数据库初始化时把时区设置正确。

6.4 常见问题速查表与排查思路

把项目运行过程中最容易出现的几个问题，我整理成一张表。毕设阶段遇到这些问题不用慌，基本都是环境或配置层面的原因，解决起来很快。

6.5 部署时避免踩的几个“隐形坑”

最后再补充几个部署阶段特有的坑：

第一个坑：前后端部署在同一台Nginx上，但刷新前端页面时出现404。原因在于前端路由是History模式，刷新时Nginx找不到对应的静态文件路径。解决办法是在Nginx的location配置里加try_files $uri $uri/ /index.html;。这个坑非常常见，一定要写入部署文档。

第二个坑：上传图片后，浏览器能通过后端地址打开图片，但通过前端域名打开就404。原因还是Nginx没配置图片访问路径的代理。要确保访问/upload路径时也能转发到后端或图片实际存储目录。

第三个坑：JAR包启动后进程被系统杀掉。终端执行java -jar，关闭终端就停服务。解决办法是使用nohup java -jar xxx.jar &后台运行，或者用systemd配置成服务。写部署文档时一定要把这一条写清楚。

第四个坑：MySQL只允许本地连接，远端工具连不上。如果后端和数据库不在同一台机器上，需要修改MySQL监听地址和用户权限；如果是同一台服务器，可以不用远程连接，但用工具远程导入数据时会不方便，建议部署文档里同时提供命令行导入SQL的方法。

实操总结与个人体会

做完这个项目，我最深的体会是：毕业设计其实是一次完整的“工程化思维”训练。代码能不能跑当然重要，但更重要的是一整套交付逻辑——怎么设计数据表、怎么划分功能模块、怎么控制权限、怎么打包部署、怎么把过程写进论文。把这些环节全部走通一遍，你收获的不只是一个系统，而是一套以后做任何项目都能用上的思考框架。

最后分享一个我在开发时常用的小技巧：先写完数据库的建表语句和初始测试数据，再开始写后端接口，最后做前端页面。为什么这个顺序最好用？因为数据库是系统的地基，表结构定了，后端实体类和接口才有依据；后端接口定了，前端拿到数据结构后就能按JSON字段来渲染页面。如果反过来先写前端，很可能出现“页面写好了但后端没这个接口”或“后端返回的字段和前端对不上”的尴尬情况，来回改代码非常消耗时间和信心。

按这个顺序推进，通常两周左右能把核心功能写完整，再用一周补测试数据、优化页面细节、整理部署文档，整个项目就会非常扎实。希望这些内容对你做同类题目或者学习前后端分离开发有帮助。