做计算机毕业设计，选到"民族文化+旅游+SpringBoot"这个组合的，这两年我见了太多。禄劝这个具体场景，背后其实是一个非常典型的文旅融合需求：地方上有丰富的少数民族文化资源需要展示，游客需要一个集中的入口去了解景点、线路、民俗活动和特色美食，而毕业设计又需要一个能体现完整业务闭环的Web系统。这三件事叠在一起，就构成了这个项目的核心。

这个项目做出来是什么样子？一句话概括：基于SpringBoot的禄劝民族文化与旅游综合服务平台，分前台展示和后台管理两大块。前台面向普通游客，提供民族文化资讯、景点介绍、旅游线路推荐、特色美食、民俗活动（比如彝族火把节）等内容查询和浏览；后台供管理员维护这些内容，管理用户、处理留言咨询。技术栈以SpringBoot为核心，配合MySQL存储数据，用Thymeleaf做服务端渲染，整个项目既能完整跑通业务，又符合毕业设计对技术覆盖面和应用场景的要求。

这篇文章我就以实际开发者的视角，把这个项目从选题思路、架构设计到核心功能实现、踩坑排查，完整梳理一遍。不管你是准备拿这个题目做毕设，还是单纯想了解文旅类Web系统怎么搭建，都能从中拿到可以直接复用的东西。

1. 项目背景与选题思路

1.1 这个项目到底在解决什么问题

先聊聊禄劝这个地方。禄劝是昆明下辖的彝苗族自治县，彝族、苗族人口占比很高，民族文化资源相当丰富。火把节、彝族的服饰刺绣、苗族的芦笙歌舞，再加上轿子雪山这样的自然景观和各类特色农产品，其实是一个典型的"有资源、缺平台"的地方。线下有内容，但线上缺少一个集中展示和服务的入口。游客想查攻略、看活动安排、规划线路，只能靠零散的信息，体验很割裂。

从毕业设计角度看，这个场景恰好能撑起一个完整的业务系统：内容管理（文化资讯、景点、线路、美食、活动）、用户系统（注册、登录、收藏、评论）、交互功能（在线咨询、预约）。既有静态展示，又有动态数据，CRUD全覆盖，还能加搜索、分页、文件上传这些常见功能点。特别重要的一点是，这个题目有明显的"社会价值"可以讲——民族文化数字化展示和旅游推广，在答辩时比纯电商或纯管理系统更好立意。

1.2 为什么技术栈选了SpringBoot

这个问题每年都会被问。说实话，现在做Java方向的毕设，SpringBoot基本是默认答案，但你要能说清楚为什么选它，这本身就是答辩的加分项。

第一，SpringBoot解决了传统SSH/SSM框架配置繁琐的问题。以前用Spring MVC要写一堆XML配置，数据源、事务、视图解析器全都要手动配。SpringBoot的自动装配把这些默认行为封装好了，一个@SpringBootApplication注解就能启动一个可运行的Web应用，开发效率高出一大截。对于毕设这种时间紧凑的项目，这个优势极其实际。

第二，SpringBoot生态完整，周边组件齐全。操作数据库有MyBatis-Plus，缓存有Redis，模板渲染有Thymeleaf，安全认证有Spring Security或Shiro，几乎每个环节都有成熟方案。做文旅平台这种业务型项目，不需要造轮子，把生态组件按需组装起来就行。

第三，面试和答辩有东西可讲。SpringBoot的自动装配原理、起步依赖机制、内嵌Tomcat的设计，都是高频考点。项目选了SpringBoot，你至少有底气回答"为什么用这个框架，它相比SSM好在哪里"。

我见过有人用Vue做前后端分离，也不是不行，但如果你的Java基础一般，我建议从Thymeleaf服务端渲染起步。逻辑更集中，调试更简单，演示时也不容易出现跨域问题。

1.3 这个项目适合什么样的毕设定位

禄劝文旅平台这个题目，适合想走"业务完整度"路线的同学。它不像纯后台管理系统那样单调，也不像高并发秒杀系统那样技术门槛高，它的核心价值在于业务场景真实、模块之间关联性强、功能覆盖全面。

具体的定位建议是：做一个"可运行、可演示、可讲解"的三可项目。可运行指环境配置简单，MySQL建库导入脚本就能跑；可演示指要有足够真实感的测试数据，页面视觉效果不能太简陋；可讲解指每一个技术点你都能说清楚来龙去脉。这个项目天然具备这些条件，关键看你愿不愿意把细节做实。

2. 系统架构与核心设计

2.1 技术栈选型与理由

这个项目我用的技术栈如下：

选SpringBoot 2.7而不是3.x，原因很直接：3.x要求JDK17，不少老教程和老插件对它的支持还不完善。毕业设计用2.7加JDK8是最稳的组合，遇到问题搜得到答案，老师的环境也大概率是JDK8。

MyBatis-Plus比原生MyBatis好用得多。通用selectById、selectPage、updateById直接调用，省掉大量重复的Mapper XML。分页插件PaginationInnerInterceptor配好之后，Page对象传参就能分页查询，比手写LIMIT干净太多。

2.2 数据库设计：核心表怎么规划

文旅平台的数据模型，我把它拆成四个域：用户域、内容域、交互域、业务域（可选的有预约功能）。

用户域两张表：

• sys_user：普通用户，字段有用户名、密码（BCrypt加密）、昵称、手机号、头像、注册时间
• sys_admin：管理员，字段类似，单独建表是为了后台权限隔离清晰

内容域五张表：

• culture_article：文化资讯，标题、封面图、正文、作者、发布时间、点击量
• attraction：景点，名称、简介、详情、封面图、地址、开放时间、门票价格、类型
• travel_route：旅游线路，线路名称、天数、行程安排、价格、封面图
• food：特色美食，名称、介绍、图片、推荐指数
• festival：民俗活动，活动名称、时间、地点、介绍、状态

交互域三张表：

• user_comment：评论，关联用户、目标类型、目标ID、内容、时间
• user_favorite：收藏，关联用户、目标类型、目标ID、时间
• message_board：留言咨询，用户名称、联系方式、留言内容、回复内容、状态

每个表都建议带上公共字段：create_time、update_time、deleted、status。逻辑删除这个点必须强调：毕设中如果做物理删除，误删数据只能干瞪眼。用逻辑删除配合MyBatis-Plus的@TableLogic注解，删除操作只是更新一个标记位，数据还在，可追溯，这同时也是答辩时的一个技术亮点。

2.3 前台与后台的模块划分

系统按角色分成两块。

前台给游客和注册用户用：首页展示推荐内容，文化资讯列表与详情、景点列表与详情、旅游线路列表、特色美食板块、民俗活动列表、个人中心（修改资料、收藏管理、我的留言）。

后台给管理员用：登录认证、内容管理（五类内容的增删改查）、用户管理、留言处理、数据概览（文章数、用户数、景点数统计）。

模块划分的核心原则是：先画页面流转图，再写代码。很多同学上来就写实体类，结果做着做着发现页面之间没有交互逻辑，返工成本很高。我的做法是先把前台每个页面列出来，标注它需要后端提供哪些数据接口，再反推Controller和Service层要设计哪些方法。页面驱动开发，比代码驱动页面要合理得多。

2.4 项目目录结构与分层

一个清晰的目录结构，本身就是答辩时给老师的第一印象。我习惯这么分：

src/main/java/com/example/luquan/ ├── controller/ # 控制层，接收参数、返回视图或JSON ├── service/ # 业务层，接口+实现类 ├── mapper/ # 数据访问层，继承BaseMapper ├── entity/ # 实体类，对应数据库表 ├── config/ # 配置类（拦截器、MyBatisPlus分页等） ├── interceptor/ # 登录拦截器 ├── common/ # 公共类（统一返回结果、常量） └── utils/ # 工具类

模板文件放在src/main/resources/templates/下，按模块建子目录：user、attraction、route、culture、admin，静态资源放static/css、static/js、static/images。后台管理我单独建了一套模板目录templates/admin，和前台完全隔离，逻辑上更清晰。

3. 核心功能实现与实操要点

3.1 内容管理模块：不只是CRUD

内容管理覆盖资讯、景点、线路、美食、活动五类，本质上是"列表+详情+后台维护"的结构，但有三个细节值得展开。

第一，图片上传。文旅网站对图片的需求量非常大，景点、美食、活动都需要封面图。我用本地存储方案：在配置类中注册一个资源映射，把磁盘上的upload目录映射为/upload/**的URL路径。前端表单提交multipart文件，后端用MultipartFile.transferTo()保存文件，文件名用UUID.randomUUID()生成，避免中文名乱码和重名覆盖。

第二，富文本正文。文化资讯的正文建议集成一个轻量富文本编辑器，比如wangEditor。这里有个坑：富文本内容如果直接存数据库，在Thymeleaf模板中输出时必须用th:utext而是不是th:text。th:text会把HTML标签全部转义成普通字符串显示出来，页面上一堆<p>标签，错得很冤。

第三，状态管理。内容要有上架/下架状态，前台只查status=1的数据，管理员可随时调整。这样临时下架某个过期活动不需要删数据，也避免了活动结束后前台还在展示的尴尬。

3.2 景点与线路：关联筛选怎么做

线路推荐不能只做简单的CRUD，至少要体现"关联"和"筛选"两个业务点。

关联体现在：一个线路可以包含多个景点，需要一张关联表route_attraction_rel，记录线路ID和景点ID的对应关系。前端线路详情页展示途经景点列表，可以用MyBatis-Plus查两次再组装，也可以用自定义SQL联表查询。毕设阶段不追求极致性能，但逻辑要清晰，最好在Service层做好组装，别把循环查询散落到Controller里。

筛选体现在：景点列表按地区和类型筛选，线路列表按天数和价格区间筛选。用MyBatis-Plus的LambdaQueryWrapper动态拼接查询条件，前端通过GET参数传递筛选条件，后端接收后构建Wrapper。这里必须注意空值判断，比如StringUtils.isNotBlank(type)再拼接eq，否则前端没传该参数时，SQL多加一个无条件限制，查出来永远为空。

首页推荐位可以做一个"热门景点Top5"排行榜，实现方式很简单：attraction表加view_count字段，每次查看详情时执行UPDATE attraction SET view_count = view_count + 1 WHERE id = ?，列表查询按view_count倒序取前N条。这个逻辑不难，但演示效果很好，答辩时可以讲设计思路。

3.3 用户系统与登录拦截

用户系统是毕设里绕不开的部分。注册、登录、退出、修改密码、忘记密码，这些基础功能要完整。

密码存储必须用BCrypt加密，Spring Security中的BCryptPasswordEncoder可以直接引入使用，不需要把整个安全框架都引进来。我再次强调：密码绝不能明文存数据库，这是答辩时老师重点检查的安全红线。

登录状态用Session管理。登录成功后把用户对象放入Session，然后写一个LoginInterceptor实现HandlerInterceptor接口，在preHandle中判断Session中是否有用户，没有就重定向到登录页。这是一个标准做法，比写一堆if判断高得多。

3.4 交互功能：评论与留言咨询

交互功能我做了两块：评论和留言咨询。

评论针对景点和资讯，登录用户才能发表。评论表的设计用target_type和target_id两个字段区分评论归属，比给每个模块单独建评论表要优雅得多。target_type可以用常量区分，比如1代表景点、2代表资讯，查询时构造wrapper.eq("target_type", type).eq("target_id", id)即可。

留言咨询是游客给管理员发消息，管理员在后台回复。这个功能表结构简单，但要注意设计一个状态字段：未回复、已回复。后台列表按未回复优先排序，方便管理员处理。

4. 实操过程与关键代码走读

4.1 项目初始化的版本坑

用Spring Initializr生成项目时，默认可能生成3.x版本，需要手动切换到2.7.x。生成后第一件事是检查pom.xml里的版本号，确认是2.7.x再继续。我见过同学用3.x配了网上2.x的教程代码，编译期各种报错，折腾两天才反应过来是版本不对。

依赖方面，我选了：Spring Web、Thymeleaf、MyBatis Framework（后续替换成MyBatis-Plus的starter）、MySQL Driver、Lombok。注意MyBatis-Plus要单独引入它的starter依赖，不是Spring官方那个。

4.2 配置文件里的关键细节

application.yml是项目的命脉，我贴一份经过完整测试的配置：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/luquan_tourism?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver thymeleaf: cache: false servlet: multipart: max-file-size: 10MB max-request-size: 20MB mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

三个重点：第一，数据库连接URL必须带useUnicode=true&characterEncoding=utf8和serverTimezone=Asia/Shanghai，少了前者中文乱码，少了后者可能报时区错误。第二，开发阶段务必开启log-impl: StdOutImpl，每条SQL都会打印到控制台，排查问题直观到你不敢相信。第三，logic-delete-field配置了逻辑删除字段，所有delete操作自动变为update，极其省心。

4.3 景点模块的完整代码路径

以景点模块为例，走一遍完整的代码路径。

实体类：

@Data @TableName("attraction") public class Attraction { @TableId(type = IdType.AUTO) private Long id; private String name; private String summary; private String detail; private String coverImage; private String address; private String openTime; private BigDecimal ticketPrice; private String type; private Integer viewCount; private Integer status; private LocalDateTime createTime; private LocalDateTime updateTime; @TableLogic private Integer deleted; }

Controller层只做参数接收和数据传递：

@Controller @RequestMapping("/attraction") public class AttractionController { @Autowired private AttractionService attractionService; @GetMapping("/list") public String list(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(required = false) String type, @RequestParam(required = false) String keyword, Model model) { Page<Attraction> page = attractionService.getPage(pageNum, 10, type, keyword); model.addAttribute("page", page); return "attraction/list"; } @GetMapping("/detail/{id}") public String detail(@PathVariable Long id, Model model) { attractionService.increaseViewCount(id); model.addAttribute("attraction", attractionService.getById(id)); return "attraction/detail"; } }

Service层实现分页和条件查询：

public Page<Attraction> getPage(Integer pageNum, Integer pageSize, String type, String keyword) { Page<Attraction> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Attraction> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Attraction::getStatus, 1) .eq(StringUtils.isNotBlank(type), Attraction::getType, type) .like(StringUtils.isNotBlank(keyword), Attraction::getName, keyword) .orderByDesc(Attraction::getViewCount); return attractionMapper.selectPage(page, wrapper); }

这段代码是整篇的核心之一。LambdaQueryWrapper比普通QueryWrapper安全，字段名用方法引用，编译期就能发现写错字段的问题。StringUtils.isNotBlank判断参数是否为空，空就不拼接条件，避免无效查询条件。

4.4 分页插件和拦截器注册

MyBatis-Plus分页插件必须显式配置，不配置selectPage不生效：

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

登录拦截器写法：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/user/login"); return false; } return true; } }

注册拦截器时，有个特别容易踩的坑——静态资源路径必须排除：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/user/**", "/comment/add", "/favorite/**") .excludePathPatterns("/user/login", "/user/register", "/css/**", "/js/**", "/images/**", "/upload/**"); } }

我第一版漏了静态资源排除，结果CSS和JS全被拦截，页面样式丢得一干二净，排查了半小时才反应过来。这个坑特别典型，写出来提醒大家。

5. 常见问题与排查技巧

5.1 高频报错速查表

开发过程中我遇到并解决了一批典型问题，整理成速查表：

5.2 演示和答辩的注意事项

毕设项目不只是能跑，还要禁得起演示和提问。

演示前一定准备好测试数据。至少5条景点、10条资讯、3条线路，数据要有真实感。我见过太多人演示时页面空空如也，效果大打折扣。测试数据的图片可以用真实场景图，注意版权，用免费图库即可。火把节、轿子雪山这些内容，配图选有代表性的，视觉冲击力强。

答辩时可能被问到的点提前准备：为什么用逻辑删除、分页怎么实现、登录凭证存在哪里、密码怎么加密、为什么用Thymeleaf不用Vue。这些都是常见问题，每年都有同学答不上来。还有一个高频追问："如果用户量大了，这个系统哪里最先成为瓶颈？"答案可以指向数据库查询压力，引申出加Redis缓存热门景点的优化方案，这个回答会显得你有思考深度。

5.3 后台管理端的权限控制细节

后台管理是独立的登录体系，管理员表和管理员登录页与前台完全分开。管理员登录后Session存入loginAdmin，后台所有请求路径统一以/admin/开头，拦截器判断是否管理员登录，未登录直接跳转到管理员登录页。这里要特别注意：管理员拦截器不能和用户拦截器共用，否则会出现"用户登录了就能进后台"的严重漏洞。我在设计时特意用了两个不同的Session关键字和两套拦截规则，后台模板也放在独立的admin目录下，从路径到逻辑完全隔离。

给后台列表页加一个简单的关键词搜索框，搜索景点名称或资讯标题，用like查询拼条件，交互上比纯列表好很多。后台的删除操作全部走逻辑删除，数据不真正消失，演示时可以放心操作。

6. 一些经验和后续扩展的想法

做这个项目最大的收获，不是学会了SpringBoot的某个API，而是搞明白了"一个完整的业务系统是怎么从需求变成代码的"。选题的时候你可能觉得文旅平台很普通，但真正把一个业务闭环做出来，从数据库设计到页面展示，再到拦截器和异常处理，每一环都在逼你想清楚"为什么这样做"。

最后分享几个我在实操中的体会。

第一，先跑通再优化。不要一开始就想把代码写得完美，先把最简流程跑通——数据库建表、实体类、列表页、详情页，这一条链路通了，项目就有了骨架，后面加功能只是往骨架上填肉。我见过太多同学卡在"设计过度"上，光想着怎么把架构做完美，结果一个月过去连页面都没跑起来。

第二，报错信息是最好的老师。中文技术社区里，SpringBoot的常见问题基本都有答案，关键在于你能不能把报错信息完整地贴进搜索框。很多人一看到英文报错就慌，其实大部分报错都是在提示你：空指针、找不到Mapper、字段不存在、依赖冲突。把异常栈从第一行看到最后一行，60%的问题自己能解决。

第三，这个项目后续扩展空间很大。如果你答辩后还想继续完善，优先级建议是：给热门景点加Redis缓存、把文件上传改成MinIO对象存储、用Spring Security替换手写拦截器、前后端分离改造。这四个方向任何一个都能写出一篇单独的技术笔记，也是面试时极好的项目深挖点。

对于正在选题或者正在挣扎的学弟学妹，我的建议是：不要贪大求全，把基础功能做扎实，把关键技术的原理弄懂，比堆砌十几个华而不实的功能有用得多。一个能讲清楚原理、经得起追问的项目，才是毕业设计该有的样子。