前阵子有个学弟找我聊毕业设计选题他说想做个网页类的系统但不想再做那种千篇一律的图书管理、学生管理系统。我听到他想做旅游相关的方向第一反应是认同——旅游网站场景贴近生活数据模型有一定复杂度前端页面能做得漂亮后端逻辑也够丰富不管是做毕设还是写进简历都有足够的内容可以讲。他后来定下的题目就是SpringBootVueMySQL搭建的“七彩云南文化旅游网站平台”。这个题目我帮他从头到尾梳理过一遍包括前期的技术选型、数据库设计、后端接口划分、前端页面结构、论文怎么写、部署时踩过哪些坑基本都摸过一遍。所以这篇博客想把这些内容都整理出来给正在做同类毕业设计、或者想自己从零搭一个完整前后端分离项目的同学参考。内容偏实战不绕弯子全程都是可以直接复用的思路和代码层面的方案。1. 项目整体拆解这到底是一个什么样的毕设项目1.1 题目背后的核心需求先说人话这个系统就是一个以展示云南旅游信息为主、附带用户交互功能的网站平台。它不是一个单纯展示静态页面的官网也不是一个复杂的电商系统而是介于两者之间的一个典型信息管理加用户互动平台。为什么这个题目适合做毕设原因有三个第一数据模型清晰。旅游网站的核心数据无非就是景点、旅游线路、酒店、攻略文章、用户评论这几类每个实体的字段和关联关系都非常直观不会像电商系统那样要处理购物车、库存、促销、支付分账那一大堆复杂逻辑。第二业务场景完整。既有游客角色的浏览、搜索、评论、收藏也有管理员后端的景点管理、线路管理、用户管理、评论审核天然形成一套“前台展示后台管理”的双端结构正好覆盖了毕业设计常见的功能要求。第三技术栈典型。后端SpringBoot负责业务接口前端Vue负责页面渲染MySQL存数据这三样组合是当前Web开发的主流搭配答辩时不会被问到“为什么不用某某技术”这种难堪的问题。1.2 系统角色与功能边界我在拆解这个项目时通常会把角色分成三类游客未登录用户可以浏览首页、查看景点列表和详情、搜索景点、查看旅游线路和攻略文章但无法评论和收藏。注册用户登录后在游客权限基础上增加发表评论、收藏景点、查看个人收藏列表、修改个人信息等功能。管理员负责后台系统的全部管理操作包括景点信息的新增修改删除上下架、线路管理、攻略文章发布、用户管理、评论审核。这个角色划分非常经典也很有讲究。很多同学一开始会犯一个错误就是把所有功能都堆在同一个页面或者同一个角色上看起来功能倒是不少但答辩时老师一句“你的权限控制是怎么做的”就把你问住了。把角色拆清楚权限控制的实现才有说头。另外还要在前期明确一个边界这个系统要不要做支付功能要不要做真实的订单交易我的建议是不做或者只做“线路预约”级别的模拟订单。理由很简单真实支付涉及到第三方接口、回调、退款这些复杂流程对毕设来说属于“高风险、低回报”的功能写起来耗时答辩时也不一定加分。反过来如果做一个“线路报名”功能只需要用户提交意向信息、管理员后台确认这样既有了业务闭环又避开了支付复杂度性价比高很多。1.3 交付物清单的理解源码、数据库、论文、部署文档题目里提到的“源码数据库论文部署文档”其实就是这个项目的完整交付物。很多同学不明白为什么毕设要交一整套东西这里我多解释几句源码评委老师要看你真的把系统写出来了不是画个草图而已。源码要求能编译、能运行结构清晰注释适量。数据库光有源码没有数据表系统就是一个空壳。数据库SQL文件里要包含建表语句、初始测试数据最好连管理员账号一起准备好。论文这是毕业设计的文字证明描述你做了哪些工作、解决了什么问题、系统怎么设计怎么实现。部署文档用来证明你的系统不是只能在你自己电脑上跑换一台机器按照文档步骤也能跑起来。这一点在远程答辩或演示环节尤其重要。所以这个题目表面上是一个编程任务实际上是一整套“工程交付”流程。在后面几节里我会按这套交付物的顺序把关键技术点全部展开。2. 技术选型与架构分析为什么是SpringBootVueMySQL2.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处理跨域和集群环境都比较麻烦所以目前的主流方案是JWTJSON 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等图片格式防止上传恶意文件要限制文件大小比如单张图片不超过5MBSpringBoot中可以在配置里设置最大上传大小文件名不能直接用用户上传的原文件名要用时间戳加随机字符串重命名否则不同用户上传同名文件会产生覆盖问题也会出现中文文件名在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”错误。可以在连接参数里加serverTimezoneAsia/Shanghai或者在数据库初始化时把时区设置正确。6.4 常见问题速查表与排查思路把项目运行过程中最容易出现的几个问题我整理成一张表。毕设阶段遇到这些问题不用慌基本都是环境或配置层面的原因解决起来很快。现象直接原因排查与解决办法后端启动报数据库连接失败数据库地址、账号、密码错误或MySQL服务没启动检查application.yml里的连接信息确认MySQL能正常连接排查防火墙是否放行3306端口前端请求后端接口404前端代理配置错误或后端路由不对检查网络面板里请求的实际URL确认代理规则或接口路径拼写是否正确前端请求后端接口跨域报错跨域拦截或代理未生效开发环境检查Vue代理配置部署环境确认Nginx的/api转发配置登录后页面刷新就掉线前端只存了内存状态或刷新时没恢复登录状态确保登录后Token存到localStorage路由守卫和axios拦截器里统一读取图片上传成功但访问403或404上传目录路径配置错误或没有静态资源映射检查上传目录是否存在、Nginx是否配置了图片目录的访问权限接口返回500但日志无异常全局异常处理吞掉了日志或日志级别设置太高检查全局异常处理器把异常堆栈打到日志并适当调整日志级别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字段来渲染页面。如果反过来先写前端很可能出现“页面写好了但后端没这个接口”或“后端返回的字段和前端对不上”的尴尬情况来回改代码非常消耗时间和信心。按这个顺序推进通常两周左右能把核心功能写完整再用一周补测试数据、优化页面细节、整理部署文档整个项目就会非常扎实。希望这些内容对你做同类题目或者学习前后端分离开发有帮助。