企业官网建设流程全解析

去年有个读者在后台问我，准备把“springboot旅游景点攻略平台”当作毕业设计题目来做，但心里没底，不知道一个旅游攻略平台到底应该做成什么样、代码拿到手之后第一步该做什么。这其实是很多做毕设的同学共同的困惑：题目看起来简单，但真开始写代码、部署、写论文、准备答辩的时候，才发现每一环都有坑。所以这篇博客我打算把这个项目从头到尾拆一遍，我会从题目里能看出来的技术栈讲起，再补全一个毕业设计源码最可能包含的设计思路、功能模块、数据库结构和实现细节，顺带把开发过程中一定会遇到的坑和答辩的时候面试官/老师喜欢问的问题都整理出来。不管你是想用这套源码做二次开发，还是准备自己动手复刻一个类似项目，这篇文章都可以当一份少走弯路的实操手册用。

现在很多学校的毕设题目已经不是简单的SSM框架增删改查，而是明确提到了Spring Boot，这就意味着你至少需要掌握自动配置、starter依赖、配置文件分层、REST接口规范，以及如何和前端联调这类基本功。旅游景点攻略平台这个题，核心业务则是围绕“景点信息”和“用户攻略内容”展开，既要管理结构化数据，又要处理用户生成内容，还要考虑搜索、收藏、评论、审核这些场景，算是一个非常典型的全栈Web项目，很适合作为毕业设计来体现你的工程能力。下面我按照实际开发中做这个项目的顺序，从架构到数据库、从后端到前端、从启动到部署，一份一份讲清楚。

1. 项目概述与选题分析

1.1 旅游景点攻略平台到底要做什么

看到“旅游景点攻略平台”这个名字，先不要急着写代码，而是要把需求还原成几个核心问题。平台给谁用？用户在这里能做什么？平台的核心数据是什么？一个能过毕设、也能拿得出手的功能划分，通常至少要有三个端：游客端、登录用户端、管理员后台。游客可以浏览景点列表、查看攻略详情，但不允许发布内容和收藏；登录用户可以浏览、搜索、收藏景点、发布攻略、评论互动；管理员则负责审核攻略、管理景点信息、查看统计数据。这样拆下来，这个项目就不再只是“增删改查”，而是有“内容生产—内容审核—内容展示—用户互动”这么一条完整业务链条。

从开发角度讲，毕设项目最忌讳的就是堆功能，功能多到代码写不完、论文还得编。所以要抓核心主线。旅游攻略平台的命脉是内容，而内容又分成两块：景点基础信息，比如景点名称、地点、简介、图片、开放时间、门票价格；以及用户创作的攻略内容，比如游玩路线、预算、避坑建议、图文笔记。围绕这两块内容延伸出的收藏、评论、点赞、搜索才是加分项。所以如果你的源码里只看到了基本的用户登录和景点增删改查，不要觉得它“太简单”，能把这条内容链路做通，比做十个没用的模块更有说服力。

1.2 核心功能模块与角色权限拆解

我在指导学生用这类源码做二次开发时，一般会建议先把“平台角色”和“功能权限”画成一张表，哪怕只是在纸上画。因为后面写代码、建数据库表、设计前端页面的时候，很多判断都要回到这张表。比如一个普通用户访问后台管理的接口怎么办？这就需要区分角色权限。通常的做法是在用户表里加一个role字段，后端用拦截器或者Spring Security做接口级校验。

这个项目的角色与功能划分大致如下：

这里真正要留意的是“攻略审核”这个点。因为用户发布的内容如果不经过审核直接显示，容易被灌垃圾内容，也会让老师的印象分打折扣。源码里如果带了审核状态字段，答辩时一定要重点讲；如果没带，建议你自己加一个state字段，无论是做毕设还是以后写真实项目，这个机制都是通用的。

2. 技术栈选型与架构设计思路

2.1 为什么是Spring Boot而不是SSM？

如果你现在还在问这个问题，那说明你还没吃透Spring Boot的核心价值。早期SSM（Spring + Spring MVC + MyBatis）项目最大的痛点是配置太多。数据源、事务、MyBatis工厂、视图解析器，每个都得写XML，环境稍微一变就会出问题。Spring Boot出现以后，通过自动配置和starter机制，把这些繁琐的配置变成了约定俗成的默认值。你引入一个spring-boot-starter-web，它就知道你是做Web开发；引入spring-boot-starter-data-redis，它就帮你配好RedisTemplate。

所以毕设题目指定Spring Boot，并不只是为了追逐热点，而是因为它确实是现在企业级Java开发最主流的基础框架。用Spring Boot开发这个旅游攻略平台，你需要理解几个核心机制：自动配置、依赖管理和Starter、application.yml的配置优先级、内嵌Tomcat。面试时老师问你“Spring Boot自动配置原理是什么”，答不上来就很可惜了。简单说，就是启动类上的@SpringBootApplication注解组合了@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan三个注解，其中@EnableAutoConfiguration会通过SpringFactoriesLoader加载META-INF/spring.factories里配置的自动配置类，再根据条件注解@ConditionalOnClass、@ConditionalOnMissingBean等决定是否生效。我建议把这条链路背熟，再结合项目里的场景讲，比如“项目启动后为什么能直接注入DataSource？就是因为DataSourceAutoConfiguration根据classpath下的连接池和配置项帮我们自动创建了DataSource对象”。

2.2 前后端分离架构的优势和落地

这个项目的标题虽然写在前面的是Spring Boot，但从现在毕业设计的普遍情况来看，前端大概率用了Vue。Spring Boot只负责提供RESTful API，前端另起一个项目用axios调接口。前后端分离的好处是后端不用关心页面渲染，所有接口以JSON格式返回数据，前端拿到数据后再用Vue的模板语法渲染成页面。这样分开开发、分开部署，项目结构会更清晰，写论文的时候也可以单独画一张前后端交互架构图。

采用前后端分离以后需要注意两个问题：第一个是跨域问题。前端运行在localhost:8080，后端跑在localhost:8081，端口不同就属于跨域，浏览器默认会拦截非简单请求。解决办法要么在后端写一个CorsConfig配置类，要么通过网关统一转发。最常见的做法是使用@CrossOrigin注解或实现WebMvcConfigurer接口。我见过不少同学把跨域配置写成允许所有来源“*”，如果同时开了认证，会带来安全隐患，建议前后端联调时固定允许的域名和端口。第二个是接口规范问题。前后端分离模式下，接口的数据结构最好是统一风格。

我这里的做法是封装一个统一的返回体Result类，里面包括code、message、data三个字段。比如查询成功返回200，参数错误返回400，未登录返回401，服务器无权限返回403，系统异常返回500。前端在axios响应拦截器里统一判断code，不需要每个页面都写一大堆异常处理。

2.3 数据存储选型：MySQL + Redis 的组合

旅游攻略核心数据是景点信息和用户发布的内容。这类数据都是结构化数据，之间存在明确关系，比如一个景点下有多条评论、一个用户可以收藏多个景点，最适合存MySQL。在毕设里，MySQL数据库设计本身也是重点考核的一部分。你需要建哪些表、表之间怎么关联、哪些字段适合建索引，这部分我会在下一章详细拆。

Redis在这个项目里是点睛之笔。如果源码里没有引入Redis，我建议你至少做两件事：一是把首页的热门景点缓存到Redis，减轻数据库压力，这个比较好解释；二是把验证码或者登录Token存到Redis，这样数据有过期时间，也不用每次到数据库查。这会让项目更有技术含量。实际开发中，Redis可以存热门景点的浏览量、收藏数的计数器，也可以用Redis的Set结构实现点赞状态的记录。做毕设不需要太复杂，能说清楚缓存穿透、缓存击穿、缓存雪崩的区别和应对方式就已经比大部分同学强了。面试顺带考Redis的时候，你完全可以结合项目里缓存热门的逻辑，讲讲缓存刷新策略：查询时先查Redis，如果缓存没有再去查MySQL，然后把结果写入Redis并设置过期时间，这就是最常见的Cache Aside Pattern。

2.4 为什么ORM选择MyBatis-Plus

Spring Boot整合MyBatis是历届毕设里最经典的组合。如果源码用的是MyBatis，那正常就是自己写SQL，配mapper.xml；如果是MyBatis-Plus，大部分单表CRUD不用写SQL，继承一个BaseMapper接口就能用selectById、selectPage这些现成方法，做分页、条件查询都很方便。这几年毕设源码带MyBatis-Plus的越来越多，因为这个工具确实让开发者开发速度快很多。

关于版本坑，这里要扎心提醒一句。很多毕设源码给的是Spring Boot 2.7和MyBatis-Plus 3.5的搭配，如果你图新装了Spring Boot 3.x，那问题就来了：Spring Boot 3基于Jakarta EE规范，默认包名从javax改成了jakarta，MyBatis-Plus的早期版本不兼容，启动时可能会报ClassNotFoundException或NoClassDefFoundError。所以拿到源码先确认版本，如果是Spring Boot 2.7就别轻易升到3.x。如果非要使用新版本，请把MyBatis-Plus也升级到对应支持Spring Boot 3的版本，并且修改所有import javax为jakarta。这种基础设施方面的版本兼容问题，现在越来越多被当成简历和面试中的加分点。

3. 数据库设计与核心表结构拆解

3.1 数据库设计的基本原则

在设计旅游攻略平台的数据库时，我记得最深刻的一条原则是：不要为了追求范式而让业务查询变得极度复杂。毕设系统数据量不大，应该优先考虑查询方便，因此可以适当冗余一些字段。比如景点表里直接冗余一个区域名称字段，或者统计点赞数时在景点表或攻略表里加一个favorite_count字段，每次点赞操作的时候update这个字段，就不用查询时count一下了。

另一个原则是：核心业务表一定要有基础字段。所谓基础字段，就是id、create_time、update_time、deleted这类字段。id主键建议用自增或者雪花算法。create_time用于记录发布时间，后面做列表排序、论文里画ER图都会用到。deleted字段用于逻辑删除，因为用户发布的内容如果物理删掉了，关联的评论、收藏记录可能会有脏数据，用逻辑删除可以保留数据的完整性，同时也能增加一个讲“为什么不物理删除”的答辩点。

3.2 核心表设计清单与字段说明

这个项目数据库通常至少包含这些表：用户表（user）、景点表（scenic_spot）、攻略表（strategy）、攻略评论表（comment）、收藏表（favorite）、轮播图表（banner）、公告表（notice），有些还会有攻略图片表或者标签表。各表之间的关系是：用户对景点有收藏多对多，所以需要收藏关系表；用户对攻略有评论一对多；用户和攻略之间是发布者关系，一个用户可以发布多条攻略。

下面是几个关键表的字段设计参考，实际使用源码时请先核对PowerDesigner图或SQL脚本中的命名再改。

用户表（user）的核心字段：

这里提几个细节。密码一般不会明文存，会用MD5加盐，或者用BCrypt加密，后者更安全，Spring Security默认就支持BCrypt。如果你用的是Spring Security框架，登录注册部分的密码必须要用BCryptPasswordEncoder而不是自己写个MD5工具类。手机号、邮箱这类信息能不给权限就不给前端拿全套，防止个人隐私问题。

景点表（scenic_spot）的字段可以包含名称、封面图、所在省份、城市、区域、详细地址、封面图片、景区介绍、开放时间、建议游玩时长、门票价格、热度值（浏览量）、状态，以及经纬度，如果后面想接入地图的话会有用。字段不需要说得特别全，但图片地址最好存相对路径而不是把整个base64图片塞进数据库。部分毕设会把景区图片上传到本地磁盘，数据库里只存一个类似“/upload/image/xxx.jpg”的路径，前端再通过后端资源映射去访问。这里就涉及Spring Boot静态资源映射问题，如果你把图片存在了本地方目录，要让浏览器能访问到，需要配置一个资源映射器把虚拟路径映射到磁盘路径，或者直接将upload目录加到resources静态目录。如果不知道这一点，上传完图片网页死活不显示也不奇怪了。

攻略表（strategy）的核心设计如下：

评论区设计稍微注意一下，如果你只做一级评论，那comment表就不用加parent_id；若是做楼中楼回复，就需要一个parent_id或reply_id字段来记录父评论。我一贯建议同学不要把回复层级搞太深，两级评论足够展现设计能力了，做到三级以上很容易把自己绕晕。

3.3 一个标准的建表SQL示例

既然讲到数据库，直接给一个景点表的SQL参考。这里使用的是MySQL语法，大家在自己库里执行时，请根据实际字段调整。如果字段命名和你下载的源码不一致，再动表结构也可以，否则直接使用下面的建表语句。

CREATE TABLE `scenic_spot` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '景点ID', `name` varchar(100) NOT NULL COMMENT '景点名称', `cover_image` varchar(255) DEFAULT NULL COMMENT '景点封面图', `province` varchar(50) DEFAULT NULL COMMENT '省份', `city` varchar(50) DEFAULT NULL COMMENT '城市', `address` varchar(255) DEFAULT NULL COMMENT '详细地址', `description` text COMMENT '景点介绍', `open_time` varchar(50) DEFAULT NULL COMMENT '开放时间', `ticket_price` decimal(10,2) DEFAULT '0.00' COMMENT '门票价格', `level` varchar(20) DEFAULT NULL COMMENT '景区等级，如5A', `view_count` int(11) DEFAULT '0' COMMENT '浏览量', `status` tinyint(4) DEFAULT '1' COMMENT '状态：1上架 0下架', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `deleted` tinyint(1) DEFAULT '0' COMMENT '逻辑删除标记', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='旅游景点信息表';

注意字符集一定要用utf8mb4而不是utf8，因为utf8在MySQL里不是真正的UTF-8，它最多只能存3个字节，而用户在攻略里很可能输入emoji表情，emoji需要4个字节。我见过不少同学数据库建好后，前端提交带emoji的内容进来就报Incorrect string value错误，改一下表字集就能解决。

4. 后端核心模块的实现细节

4.1 用户登录注册与JWT权限校验

用户模块是几乎所有系统的基础，做这个项目时最容易犯的错误是只写了“登录成功后把用户ID放进Session”这样的逻辑，然后就没有然后了。对前后端分离项目来说，更主流无状态认证方案是JWT。用户登录成功后，后端生成一串包含用户信息、有效期、签名算法的Token返回给前端。前端后续请求在请求头里带上Authorization: Bearer ，后端写一个拦截器解析Token，再决定是否放行。

这套逻辑可以用SpringBoot+JWT实现。拦截器里要注意的地方是：需要放行登录、注册和景点公开查询这类接口，不然用户没登录就什么都访问不了；还要处理Token过期的情况，返回给前端401状态码。前端收到401后跳转登录页，这是最基础的交互。

写一个简单的拦截器实现思路：

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 如果是OPTIONS预检请求，直接放行 if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); if (JwtUtil.validateToken(token)) { // 把用户ID存入request Long userId = JwtUtil.getUserId(token); request.setAttribute("userId", userId); return true; } } response.setStatus(401); return false; } }

如果项目里配置了Spring Security，那就不用自己写这个拦截器，直接写SecurityFilterChain和自定义UserDetailsService。但Spring Security的过滤器链比较抽象，对毕设新手来说自己搭容易在各种403、401之间迷失方向。所以如果源码用的是拦截器方案，就顺着拦截器方案去改；如果源码用的是Spring Security，就耐心把过滤器和认证管理器的代码看明白，不要中途混用。

4.2 景点管理：上传文件与资源映射

管理员新增或编辑景点时，有一个绕不开的环节：上传封面图。我在做类似项目时通常会在后台提供一个通用的文件上传接口，接收MultipartFile，然后用UUID生成新的文件名，避免用户上传了同一张名称的图片导致覆盖。文件保存路径可以写在配置文件中，比如upload.path=/data/upload。

保存文件的核心逻辑差不多是这样的：

@PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("请选择文件"); } // 获取原文件名后缀 String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); // 生成新文件名 String newFileName = UUID.randomUUID().toString().replace("-", "") + suffix; // 保存文件 File dest = new File(uploadPath + newFileName); file.transferTo(dest); // 返回可访问路径 return Result.success("/upload/" + newFileName); }

文件保存完以后，还要配置虚拟路径映射。在Spring Boot里实现WebMvcConfigurer，把/upload/**映射到file:D:/xxx/upload/这个本地路径，这样前端用就能正常显示图片。如果不在同一个域下，或者图片服务被独立部署，那一般会用Nginx处理静态文件代理。

4.3 攻略发布、审核状态管理与评论互动

这部分功能是旅游攻略平台的内容核心。用户写攻略，提交后默认状态是0待审核，管理员在后台能看到待审核列表，审核通过就改成1，拒绝则可以填写理由状态为2，用户在我的攻略列表中能看到被拒绝的原因，这需要给攻略表加一个审核备注字段。流程虽然不复杂，但在答辩时价值很高，因为它是典型的内容安全流程。

攻略内容因为使用富文本框编辑，通常会是一段HTML。后端HTML保存时要注意XSS问题，最简单的方式是使用过滤器过滤掉script标签。有的同学嫌麻烦，直接提交HTML字段，一般来说在自己本地项目问题不大，但一旦上线就很容易被脚本注入，所以建议做一层转义，比如把<替换成<，展示时再处理。如果你的项目后期想做得更有真实平台的感觉，还可以集成一个富文本编辑器组件，从组件上限制粘贴内容的标签。

评论互动也值得认真写。用户在某个景点或攻略下方发布评论时，后端需要同时记录评论对象类型、目标ID、用户ID、评论内容、评论时间。这里有个常见的坑：在循环中查评论时，如果有二级回复，很容易产生N+1次查询。数据量不大时影响不明显，但如果你学会用一条SQL把该目标下的所有评论一次性查出来，再在Java内存中组装成树形结构，就已经能体现优化的意识了。展示评论时要有“XX用户评论了这篇攻略”这种上下文，所以user表还得查出头像和昵称，通常是left join关联user表。

4.4 搜索与首页热门推荐

景点列表页基本上都要支持关键词搜索和筛选。用户在搜索框输入“杭州 西湖”，系统需要根据景点名称、城市、甚至攻略标题做模糊匹配。最基础的做法是使用MyBatis-Plus的LambdaQueryWrapper：

LambdaQueryWrapper<ScenicSpot> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(keyword)) { wrapper.and(w -> w.like(ScenicSpot::getName, keyword) .or().like(ScenicSpot::getCity, keyword) .or().like(ScenicSpot::getDescription, keyword)); } List<ScenicSpot> list = scenicSpotService.list(wrapper);

首页热门景点怎么来？通常按收藏数降序，或者按浏览量降序，取前8条。这部分逻辑可以每天凌晨用定时任务重算一次统计结果并写入Redis，也可以每次请求实时查数据库再用List排序取topN。毕设阶段不用上Elasticsearch这种搜索引擎，如果被老师问到“搜索怎么做才能更快”，可以说引入Elasticsearch建立索引是后续演进方向，但当前数据量用MySQL的like查询足够。

5. 前端项目结构与接口对接心得

5.1 Vue项目的目录组织

我虽然主要擅长后端，但前后端分离的项目看多了以后，真心建议前端也按模块来划分目录。Vue项目比较常规的目录是views下面放页面组件，比如Home、ScenicList、ScenicDetail、Login、Register、PublishStrategy、PersonalCenter、AdminManage。components下面放一些公共组件，比如导航栏、底部栏、评论组件、景点卡片。api目录下面按业务模块封装接口请求，比如api/scenic.js、api/user.js、api/strategy.js。router目录管理路由表，store目录放全局用户状态。

很多时候大家从源码拿到Vue项目，第一步是安装依赖npm install，然后npm run serve。但前端项目经常会出现node-sass下载失败或者node版本太高导致编译报错的情况。这种情况很常见，不要把时间耗在死磕环境上，可以尝试用npm config set registry换国内镜像源，或者将node-sass替换成dart-sass（对应npm包为sass）。如果项目的package-lock.json出现了各种问题，可以删除node_modules目录重新安装，必要时删除package-lock.json再重新生成。

5.2 请求封装与路由鉴权

前端请求封装通常用axios而不是原生的fetch，原因在于更成熟、拦截器更好用。在request.js中配置baseURL，超时时间设置为10秒；请求拦截器每发一次请求就从localStorage里取出token，放到headers；响应拦截器里判断返回状态码，如果code为401则提示登录过期并跳转到login页面。这样每个页面请求都不需要自己处理token，很清爽。

路由鉴权方面，可以给需要登录的路由加上meta: { requiresAuth: true }。在全局前置守卫beforeEach中判断，如果用户没有登录或没token就跳转到登录页。管理员后台页面则还需要多判断一下当前用户角色是不是admin。

5.3 联调时最容易碰到的三个问题

第一个问题是接口地址不一致。前端请求的URL和后端Controller的@RequestMapping路径稍有不同就会404，所以一定要把后端接口整理成一份API文档，或者用Swagger/Knife4j自动生成接口文档，联调时打开Swagger页面直接看。熟悉Swagger注解能够清晰展示每个接口的参数和含义，也是项目加分项。

第二个问题是后端返回的数据格式和前端预期不一致。比如后端返回一个对象，前端拿到后发现日期格式是2025-01-01T10:00:00，想显示成2025-01-01 10:00:00，处理起来很麻烦。更稳妥的办法是在后端全局配置Jackson格式化时间：在application.yml中设置spring.jackson.date-format和time-zone，或者统一在实体类的日期字段加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。

第三个问题是跨域配置在分布式情况下不够灵活。如果你是单体毕设，最省事的是在Controller类上加@CrossOrigin，再配一个WebMvcConfigurer统一解决；如果在部署时使用了Nginx反向代理，把前端和后端配到同一个域名下，通过路径区分，就从根本上规避了浏览器跨域问题。

6. 本地环境搭建与源码启动教程

6.1 准备一个干净可用的开发环境

这个项目最常见的运行环境组合是：JDK 1.8（或者21，取决于Spring Boot版本），MySQL 5.7或8.0，Redis，Maven，前端工具链。我强烈建议第一次下载毕设源码后先不急着改代码，先把环境搭好，创建一个测试数据库并导入SQL脚本，确认能跑起来再说。

打开项目前，先看pom.xml里parent的版本。如果spring-boot-starter-parent版本是2.7.x，那就用JDK 8；如果3.x就选JDK 17以上。这里特别强调一下：JDK版本不对的话，Spring Boot项目可能能编译但是运行时会报UnsupportedClassVersionError，比如“class file has wrong version 61.0, should be 55.0”，通常这个错就是编译JDK版本比运行版本高导致的。保持编译版本和运行版本一致，代码会顺畅很多。

6.2 修改配置文件后启动后端

后端核心配置基本都在src/main/resources/application.yml文件中。你需要改动的大概有这几项：数据源连接地址、数据库账号密码、Redis地址密码、文件上传路径。注意如果你的电脑上Redis没有设置密码，就不要配password，留着会无法连接。

下面是一个典型的application.yml片段：

server: port: 8080 servlet: context-path: /api spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/travel_platform?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 redis: host: localhost port: 6379 database: 0 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

如果你按上面的配置启动后仍然报错连不上MySQL，请检查MySQL服务有没有启动、密码是否正确、数据库名字是否和你导入SQL的地方一致。还有一个很容易被忽略的地方，就是driver-class-name很关键。在MySQL 8.x中驱动类为com.mysql.cj.jdbc.Driver，不要照抄网上旧版本里的com.mysql.jdbc.Driver。

数据库的SQL脚本一般在sql目录或者项目根目录下，用Navicat或命令行source导入即可。导入时如果出现报错，检查SQL文件中是否存在CREATE DATABASE语句，如果有，注意它创建出来的数据库名是否和配置文件的数据库一致，建议统一改好，避免启动后还是连空库。Java后端启动成功后日志一般会打印旅游景点攻略平台的banner，端口配置正确就可以访问。

6.3 用Docker部署Spring Boot项目

如果到答辩阶段需要演示线上部署，甚至可以展示给老师看你自己已经能打包镜像部署了，这是综合实践能力的一大亮点。最简单的做法是在项目根目录创建一个Dockerfile：

FROM openjdk:8-jdk-alpine LABEL maintainer="your name" COPY target/travel-platform.jar /app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "/app.jar"]

然后执行mvn clean package先把项目打成jar包，再把jar包和Dockerfile放到同一目录，构建镜像：

docker build -t travel-platform:latest . docker run -d --name travel-server -p 8080:8080 travel-platform:latest

需要特别注意的是，一旦你的后端跑在Docker容器里，时间会比宿主机默认差8个小时。所以数据入库时间不对时可以给容器加-e TZ=Asia/Shanghai，或者在Dockerfile里设置时区环境变量：

ENV TZ=Asia/Shanghai

日志里中文时间错乱、数据库时间不对，多半是时区没同步，这个问题我在实际开发中遇到过好几次。除了设置JVM参数-Duser.timezone=Asia/Shanghai外，也要确保数据库连接URL配了serverTimezone。

7. 常见问题与排查思路

7.1 启动失败时的排查顺序

后台启动报错是一件大概率发生的事。看到红字不要慌，一步步来：先看第一行Caused by，大多数问题的根因隐藏在最后的Caused by里面。最常见的启动报错包括端口被占用、数据库连接失败、Redis连接失败、Bean创建失败。排查顺序建议是先看端口，再去检查MySQL服务、Redis服务是否启动，然后检查配置文件，最后看依赖是否下载完整。

如果项目里引入了Redis，而且本机没装Redis，会报Unable to connect to Redis。这时候有两种方案：Windows下可以下载Redis压缩包然后执行redis-server.exe启动；也可以直接把Redis依赖从pom.xml中排除（但会失去相关功能），更推荐第一种。如果没有正式装Redis，还可以考虑用Docker开一个Redis实例作为开发环境。

我本人第一次跑类似项目时最崩溃的问题几乎都集中在“jar包冲突”和“项目结构不对”上。比如源码里引入了自定义starter，会触发一些不明确的报错，这时候控制台的关键日志比网上查任何资料都管用，不要一看到Exception就盲改代码。Ctrl+滚轮看到具体报错的类和行号，往往就是破解入口。

7.2 后端可以启动但前端接口404

如果后端已经启动，前端页面也能打开，但每次接口请求都404，排查方向有两个：第一，后端context-path配置了/API前缀，而前端请求的baseURL没有带这个前缀，导致请求路径不匹配；第二，前端请求地址是localhost:8081，但后端实际启动端口是8080，端口不一致。这类问题用浏览器的开发者工具查看Network标签就能发现。点了登录按钮，请求标红，点开看请求完整URL和路径，基本就能判断。

如果你看到的是类似于“Request method ‘POST’ not supported”的错误，意思是接口路径存在但请求方式不对，例如后端声明的是@PostMapping，但前端用GET请求，或者反之。保持RequestMapping里的method和前端axios请求方式一致是养成好习惯的第一步。

7.3 MyBatis-Plus分页不生效或者忽略deleted字段

用MyBatis-Plus分页时，一定不要忘配置PaginationInnerInterceptor插件，否则你调用selectPage时会发现返回的记录还是全量数据，分页字段没生效。需要在项目中加入一个MybatisPlusConfig配置类，注入MybatisPlusInterceptor并添加分页拦截器，示例：

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

如果你建表时加了deleted逻辑删除字段，实体类要用@TableLogic标注。这样MyBatis-Plus在执行deleteById的时候才会自动发送update语句把deleted字段置为1，而不是物理删除；查询时会自动在SQL尾巴追加deleted=0条件。有些同学在业务代码中查询时发现明明有数据却查不到，排除了权限问题后，多半是被逻辑删除条件过滤掉了。

7.4 中文乱码和数字精度问题

中文乱码主要出现在三个位置：前端传参到后端乱码、后端数据写入MySQL乱码、MySQL返回数据给前端乱码。处理办法可以“三管齐下”：请求和响应编码都设为UTF-8，数据库表的字符集设为utf8mb4，数据库连接URL加上characterEncoding=utf8。如果已经从乱码插入了数据，记得修正数据后重新插入。

用Long类型作为前端主键ID时还要注意一个折磨人的问题：JavaScript里Number能安全表示的整数最大只有2的53次方，后端生成的雪花ID很可能超过这个范围，前端拿到后精度丢失，导致更新、删除操作找不到正确记录。解决办法是后端在返回JSON时，将Long类型字段转成字符串，常见做法是引入Jackson的ToStringSerializer，或者在字段上使用@JsonSerialize(using = ToStringSerializer.class)。只要前端和后端ID对不上，数据就会莫名缺失，这个坑往往要前后端一起排查很久才能发现。

8. 答辩要点与项目扩展

8.1 讲解项目时怎么突出专业度

毕设答辩的核心不是“我把代码跑起来了”，而是要讲清楚“为什么用这个技术”、“怎么实现的”、“解决了什么问题”。一般可以按这样的结构来讲：先介绍项目背景和用户痛点，然后画一张系统架构图，从浏览器发出请求开始，经过Vue前端、Axios、后端Controller、Service、Mapper，最后到达MySQL或Redis。流程上讲清楚后，再选择一个最有代表性的功能详细展开。

如果要选一个功能作为技术亮点，我最推荐“攻略发布到展示的完整状态机”。从用户在前端填写表单提交攻略，到后端校验、落库状态为待审核，到管理员登录后台拉出待审核列表，到审核通过后前台可见。这个过程覆盖了增删改查、权限控制、多角色协作、状态流转多个知识点，比只讲“登录注册”有含金量得多。

还有一个必考点是Spring Boot自动配置。答辩老师可能会随口问：你这个项目为什么引入依赖后Spring Boot就能直接运行？把这部分基础讲清楚，不只是背概念，如果你能结合代码回答，效果会特别好。

8.2 给项目增加哪些扩展功能最加分

如果你有充足时间不想只停留在源码，可以在基础功能无误的前提下适当扩展几个方向。第一个推荐方向是使用Redis缓存热门景点与首页数据。热门数据接口变动频率很低，缓存到Redis以后，能明显减少数据库压力。启动后可以在Redis可视化工具RedisInsight里看到新增的key，这是数据落到缓存的有力证据。

第二个比较推荐的是用Elasticsearch实现全文检索。难点是安装和中文分词，可能需要引入IK分词器，但一旦实现，用户搜索体验会提升一大截，项目也就更贴近真实平台。第三个方向是消息队列削峰。比如在用户发布攻略后，使用RabbitMQ异步给管理员发送提醒。这种场景真实且适合讲异步解耦。

考虑到毕设的精力，并不建议每个扩展方向都做。挑一个做精，能画出架构图，能说清数据流向，就已经是亮点；什么都想加，最后常常哪个都讲不透。

8.3 个人实操总结与几个建议

最后想聊点实在的。带这类Spring Boot旅游攻略平台项目，我踩过最大的坑不是技术本身，而是“拿到源码后不求甚解”。很多同学下载了源码，启动了项目，觉得万事大吉，结果答辩时老师随便问一个业务实现逻辑就卡壳。代码不是你写的，至少要用一周时间把关键业务跑通和看懂。你不需要看懂每一行，但至少要把登录、景点列表、攻略审核这条主流程上的Controller、Service、Mapper一层层看过去，能够说出每个接口服务哪个页面。

另外一个建议是不要忽视项目里留下的初始化数据。景点、轮播图、公告这些演示数据能让你打开首页的时候有内容可看。如果数据库里的图片链接全是外链，很可能别人本地也访问不了。首次启动后先看看主要页面有没有应有的数据，如果没有，就找找resources下是否有import.sql或data.sql。

再分享一个小技巧：给项目做一个简单的“初始化脚本”。你整理一个初始SQL脚本，不仅包含所有建表语句，还包含几个典型的示例用户、管理员、景点数据。以后在任何一台电脑上跑起来，执行一条命令创建库导入脚本即可。这个脚本既能出现在论文附录里，也能让你在答辩演示时快速初始化环境，省去不少临场出错的烦恼。

从我带项目的经验看，Spring Boot旅游景点攻略平台这个题目确实很适合用来做毕业设计。原因是它的业务不抽象，很好理解，技术栈又成熟，网上资料多，遇到问题也容易搜到。但正因为题目常见，想拿高分就更需要多问自己几个“为什么”。比如“为什么这里需要审核机制”“为什么不用Session而用JWT”“为什么分页要加拦截器”。把这些问题逐个想明白，你的代码能力、项目理解和表达水平就不会停留在“能跑通”的层次。希望这篇文章能帮你把这个项目从“难以下手”变成“心里有数”，做的时候少走一点弯路。