SSM+Vue景区自主推广平台毕设开发全攻略：从模块设计到部署答辩

1. 一个毕设题目的真实定位：景区自主推广平台到底要做什么

每年到了毕设选题季，总会有人在群里问"SSM+Vue做什么题目好"。景区自主推广平台这个方向常年都有——校内题库里有，网上成品也多，但说实话，大多数人做完之后连自己做的到底是什么功能都说不利索。如果你也是今年选定这个题目，或者正在考虑要不要选它，我建议先把下面几个问题想明白，再动手写代码。

1.1 题目拆解：名字里藏着三层信息量

"2026毕设ssm+vue旅游景区自主推广平台"，这句话拆开看，能提取出的关键信息比你想象得多：

• 技术栈限定：后端用 SSM（Spring + SpringMVC + MyBatis），前端用 Vue。这个组合决定了你的项目是前后端分离的（如果不分离，Vue 就没有意义），也决定了数据库访问层走的是 MyBatis 的 Mapper 接口加 XML 映射。
• 业务场景限定：旅游景区推广。这意味着系统需要有景区基本信息展示、路线推荐、套餐活动、用户互动这类偏 C 端的内容型功能，而不是只做简单的增删改查。
• "自主推广"是这个题目里分量最重的词：它暗示了一个前提——景区不是靠第三方 OTA 平台（比如携程、美团那种）去卖票，而是自己做自己的一套推广和预订体系。所以后台管理侧要有多角色权限（平台管理员、景区运营人员），前台要有门户级的展示和推广位配置。

很多人把毕设做成了"景点列表 + 订票流程"的电商系统，实际上偏离了"自主推广"这个核心诉求。做得好的版本，一定在内容运营、推荐位管理、动态发布、多景区独立运营这几个层面做了设计。

1.2 这类项目适合谁选，难度处在什么档位

如果你已经学完 JavaWeb、会基础的 MySQL 建表和查询，SSM+Vue 这个题目是舒适的，不会难到做不完，但也绝对不是一个下午能赶工出来的“面条代码”。

从工作量和答辩演示的角度看，这个题目有一个天然优势：它的功能边界特别适合模块化拆分。你可以把整条开发链路分成六个模块同时推进，每个模块都能在答辩时单独演示，数据流一眼能说清，不必像复杂业务系统那样要把几十张表的关系讲明白才能自圆其说。

下面我按我自己做这类项目时的实际顺序，把这套系统的完整开发链路拆给你看。我默认你已经会基础的 Spring、MySQL、Vue 语法，所以很多过于入门的话就不重复了，只讲那些真正决定项目质量和答辩成败的细节。

2. 从需求到模块边界：四类用户和六个功能域的划分方案

动手建表之前先做需求分析，这是老生常谈，但大多数毕设的项目文档里这一段都是直接从网上复制的，和最终代码对不上。我建议你自己把分析理一遍，因为答辩老师翻文档第一个就看这一章，功能对不上代码是最低级的硬伤。

2.1 系统角色确定：管理员不能只做一个

景区自主推广平台的角色划分我推荐四类，不要贪多：

这里的细节在于：未登录用户能否看内容，决定你的接口需不需要做鉴权拦截。如果所有景区详情页都必须登录才能看，你就限制了推广能力，这是业务逻辑上的不自洽。正确的做法是公开内容全放开，收藏和下单走 Token 鉴权。

2.2 六个功能域，对应六张核心表之外的设计

模块设计上，我把整个系统划分成六个域，每一块都能独立演示：

1. 门户展示域：景区主页轮播图、图文详情、开放时间、票务政策。部分内容是运营方配置的，需要在前台动态渲染。
2. 内容运营域：景区动态/公告发布、推荐活动设置、首页推广位配置（相当于给运营方一个"把某景区推到首页"的开关）。
3. 交互服务域：评论、评分、咨询留言、收藏。
4. 交易服务域：添加行程（预约或购票）、订单状态流转。
5. 用户中心域：注册登录、个人资料、我的收藏、我的订单、我的评论。
6. 管理后台域：多角色后台，表格化数据管理 + 基础统计图表。

有一点值得注意：不要把业务方和管理员塞进同一套权限里然后硬做"一个登录入口分权限跳转"。这种做法在作业里常见，但实际项目通常是分开的，你可以在前端用统一登录接口，后端根据角色给不同的路由和菜单权限，这个实现方式更贴近真实场景。

2.3 表结构设计的基本原则和一张核心关系图

表设计是整个后端开发的根基，我见过太多人栽在关联关系没理清上。通俗一点表述：景区表管"有什么"，门票/套餐表管"卖什么"，订单表管"谁买了什么"，评价表管"买完觉得怎么样"。推荐位表管"哪些景区被优先展示"，公告表管"最近发生了什么动态"。再加一张用户表，把这些串起来。

具体建表时，注意六件事：

• 景区表和运营方账户之间是一对一或一对多的关系，设计中需要把"景区归属"作为必要字段处理。
• 门票/套餐的价格字段用 decimal，不要用 float，金额精度在真实业务里非常敏感。
• 订单状态建议用 tinyint + 状态码表，0 待支付、1 已支付、2 已取消、3 已完成，不要直接存中文状态，减少后续维度的混乱。
• 图片路径字段建议存相对路径，不要存完整 URL，方便后面换域名或迁移服务器。
• 推广位建议单独建表，负责维护关联景区、排序权重、生效时间和状态，这样前后台的数据流才清楚。
• 尽量不做多对多关联表，能通过外键和中间表处理的就老老实实拆出来，以免开发后期发现自己绕进硬编码的坑。

如果你用的是 MySQL 5.7 及以上，建议引擎选 InnoDB，字符集选 utf8mb4，否则用户昵称里存 emoji 会直接报错——这个坑我在开发中碰到不止一次。

3. 后端 SSM 开发里最容易拖进度的三个硬骨头

SSM 的搭建教程网上遍地都是，我不再重复粘贴 XML 配置。这一章我专门讲为什么会拖进度的问题，以及对应的分析思路。

3.1 SpringMVC 的拦截器体系与 Token 验证

前台用户模块最需要理清的思路是：登录接口放行，业务接口校验。

我用 JWT（JSON Web Token）做登录态承载，比 Session 更贴近当前前后端分离的流行做法。注意几个关键点：

• 登录成功返回 token 给前端，前端存到 localStorage 或请求头里。
• 定义拦截器，在拦截器中解析请求头里的 token 字符串，校验签名和过期时间。
• 把解析出的 userId 放入请求域中，供 Controller 层使用。
• 不用把拦截器加到所有路径上，否则 CSS、JS、静态图片和公开景区列表都会被拦，干扰开发。

当然如果你更熟悉 Session，用 Session 也行。只是答辩时如果老师问"多个服务器部署怎么办"，你得知道 Session 需要共享存储，而 JWT 天然无状态——这就是一个很好的加分回答点。

3.2 MyBatis 动态 SQL：景区列表筛选是这个项目最典型的场景

前台景区列表一定会需要组合条件查询：按地区筛选、按景区类型筛选、按价格区间筛选、按关键词搜索，甚至加上"只查有推荐位的景区"。如果你用 Java 代码 if 拼 SQL，效率低且易错。MyBatis 的 <where> 和 <if> 标签能帮你优雅解决。

核心思路是：

xml复制<select id="selectScenicList" resultType="com.example.entity.Scenic">
    SELECT * FROM scenic
    <where>
        <if test="keyword != null and keyword != ''">
            AND (name LIKE CONCAT('%', #{keyword}, '%')
                 OR summary LIKE CONCAT('%', #{keyword}, '%'))
        </if>
        <if test="province != null and province != ''">
            AND province = #{province}
        </if>
        <if test="typeId != null">
            AND type_id = #{typeId}
        </if>
        <if test="minPrice != null">
            AND ticket_price &gt;= #{minPrice}
        </if>
        <if test="maxPrice != null">
            AND ticket_price &lt;= #{maxPrice}
        </if>
    </where>
    ORDER BY sort_weight DESC, id DESC
</select>

<where> 标签会自动去掉第一个条件前的 AND，不需要在 Java 代码里处理拼接。排序字段用 sort_weight 控制推广位优先展示——这就是自主推广在数据层的体现。

这些写法的价值在于实战过程中，动态 SQL 写法通常能省掉一次大规模的代码重构，是做得多了才会有的经验。

3.3 文件上传配置：图片上传报错 404 的排查经历

景区详情、动态发布、用户头像都会涉及图片上传。这个功能不复杂，但我在不少项目里见过同一种问题：上传成功后访问图片 404。排查过程大概是这样的：

先找出访问图片的 URL 路径。多数情况是将上传文件写到了本地磁盘目录，但 Tomcat 默认不会把你磁盘上的任意目录映射成一个可访问的静态资源路径。换一种做法，把图片放到项目的 webapp/static/upload 目录下，这样访问就不会 404 了。还有一种做法是在 SpringMVC 配置类中加一个资源映射，把 /upload/** 映射到本地的实际文件目录。两种做法都能让图片正常显示，但也各有取舍（前一种打包部署时容易丢文件，后一种需要额外配置）。我体感是，如果你只是做毕设项目，用后一种映射方案更稳当，因为文件跟项目分离，重新部署时不会因为旧的打包内容被覆盖而导致图片丢失。

4. 前端 Vue 实现：页面规划、路由守卫与接口封装

前端是整个项目最直观的"门面"。我见过不少人的后台功能做得很全，但前台页面像开发工具箱一样粗糙——这其实很影响答辩的整体印象。这一章我讲三个直接影响开发效率和演示效果的部分。

4.1 路由设计：前台门户和后台管理分开跑

项目根目录下我用 Vue Router 做路由分层，结构类似：

code复制router/
  index.js        # 路由总入口
  modules/
    portal.js     # 前台门户路由
    admin.js      # 后台管理路由

前台门户包括首页、景区列表、景区详情、登录注册、个人中心等；后台管理包括仪表盘、景区管理、订单管理、内容管理和用户管理等。

两套路由需要共用一套登录态判断逻辑。我的做法是在全局前置守卫里做判断：

javascript复制router.beforeEach((to, from, next) => {
  if (to.meta.requiresAuth) {
    const token = localStorage.getItem('token')
    if (!token) {
      next({ path: '/login', query: { redirect: to.fullPath } })
    } else {
      next()
    }
  } else {
    next()
  }
})

后台管理路由整体加上 requiresAuth: true 的 meta 标记，再在具体的子路由配置中继承，这个方案策略很清晰，也不会在跳转时出现登录校验不严谨的情况。

4.2 Axios 拦截器的两个关键配置

前后端分离项目里，Axios 是标准用法。这里有两个细节直接影响开发体验：

第一个是基础 URL 配置：用环境变量，dev 环境走 http://localhost:8080，生产环境走你的线上域名。不要写死路径，否则每次切换环境都要全局改一遍代码。

第二个是响应拦截器：后端在用户未登录或 token 过期时会返回 401，前端拦截器统一处理，跳转登录页并提示"登录已过期，请重新登录"。这样可以避免每个页面都写一套异常判断。

javascript复制service.interceptors.response.use(
  (response) => response.data,
  (error) => {
    if (error.response && error.response.status === 401) {
      localStorage.removeItem('token')
      router.push({ path: '/login' })
    }
    return Promise.reject(error)
  }
)

统一处理之后，代码里不会到处散落着 if (res.code === 401) 的判断，项目漂亮很多。

4.3 首页推广位：这是"自主推广"最直观的前端体现

首页推广位建议设计成可配置的动态区块。前台从后端接口读取当前有效的推广位配置，再根据配置去加载对应的景区数据。这样运营方在后台调整推荐顺序或者上下架推广内容，前台无需发版即可生效。

另外景区详情页的图片展示，可以用 Element UI 的 Carousel 轮播组件，视觉上比一张静态大图有说服力。前台整体框架如果你不想从零手动搭布局，用 Vue 生态里成熟的组件库是合理选择（比如 Element UI 或 Element Plus 对应不同版本），省时间且组件样式统一。网上有大量这类成熟框架，不妨借用并做适量定制。

5. 开发中的难点与应对：从空指针到并发扣减，逐个拆解

说实话，做过几个类似项目之后，你会发现这些项目表面上的业务代码大家都在写，真正的差距在"遇到问题怎么排查"和"有没有踩过坑、知道下一步往哪里看"。

5.1 登录状态掉了：前端拿到了 token 但刷新就失效

有一次我在演示过程中发现，用户信息弹窗偶尔不出现，刷新页面多次之后又正常。后来排查到根因是：前端刷新时重新执行了 created 生命周期，而后端校验 token 的接口要求必须带着请求头信息，但我的 Axios 请求头配置里用的是 localStorage.getItem('token')，逻辑本身没问题，问题出在时序上——路由守卫先执行了，此时 token 还没有同步到 request 拦截器里，结果产生了不稳定的表现。

最终解决起来也不难。把 token 的存取统一收敛到一个独立的 auth 工具模块中，然后让所有需要用户信息的请求都通过它拿到 token，不在页面里散着写 localStorage。你实践下来会发现，token 逻辑的收敛越彻底，这类"莫名其妙失效"的问题越少。

5.2 推荐位排序权重：想让某个景区排前面，改哪儿？

如果你在后台做推荐位管理时仍然用"拖动排序后存顺序号"的思路，那要多考虑并发问题。通常的实践是给景区或推荐位表加一个 sort_weight 整数列，运营方配置的数字越大越靠前。排序接口只需要更新该列的数值即可，不需要维护一个复杂的位置字符串，既简单又可以在数据库层用 ORDER BY sort_weight DESC 直接排序。

5.3 订单状态并发更新

用户点击"立即预约"时，后台要做两件事：校验该景区当日预约名额是否足够，创建订单并锁定名额。如果名额总量设得很大（比如 9999），你很难在测试时测出并发问题；但一旦名额设小（比如每日限量 100 人），多人同时预约时就有可能出现超卖风险。

毕设项目中，你可以用两种处理思路来兼顾代码简单和安全可靠：

• MySQL 更新语句直接带上条件，例如 UPDATE scenic SET remain_count = remain_count - 1 WHERE id = ? AND remain_count > 0，这样不会扣成负数。
• 加一个简单的乐观锁字段 version，更新前比对版本号。

对于答辩来说，能解释清楚"我从数据层面避免了超卖风险"，本身就比单纯完成功能多一个加分点。

6. 部署与演示：别让环境问题毁掉你的答辩前夜

很多人的项目代码本身没有大问题，却在部署演示阶段翻车。这一章我总结我在部署这类项目时遇到过的三类高频问题，以及对应的避坑策略。

6.1 本机部署时端口占用和跨域

后端默认用 8080，前端开发服务器默认用 8081 或 5173 之类的前端服务端口，浏览器会做跨域拦截。最省事的方案是开发环境用后端 CORS 开放接口：加一个 CORS 过滤器，允许来自你前端开发服务器的请求。但我建议你留一个心眼——开发环境的跨域配置不要照搬到生产环境，生产环境要么同域部署（前端打包后放进后端静态目录），要么用反向代理转发，否则安全性欠佳。

6.2 数据库初始化

在提供项目时，你需要让其他人一键跑起来。建议准备 init.sql（建库建表），再准备一份 data.sql（初始数据）——后者尤其重要，不然答辩时后台空空如也，功能演示没有任何素材可看。请一定尽快把演示数据补齐，比如六个景区以上、几张订单、用户评论若干。当时我在这部分吃得亏是，边开发边录入测试数据，最后导出 SQL 时少了两张表的造数记录，导致演示时动态列表页是空的。

6.3 答辩演示前做的收尾检查

我在给模拟项目做正式交付前，会拉一张 Checklist，重点过几项：

• 未登录状态访问前台页面是否正常，需要登录的按钮是否会引导到登录页，而不是报跨域错。
• 后台每个菜单是否能正常打开表格并加载数据，还是出现"权限不足"这样的运行时异常。
• 刷新前台页面时是否存在无法定位的资源路径，特别是打包后部署时会遇到的 404。
• 数据库连接配置是否用了 localhost 硬编码，迁移部署时会踩坑。

7. 论文写作：从需求分析到测试用例的完整内容组织

如果你选的是"论文+程序"，那程序设计做完的一半，另一半在论文。这一章我把论文各章做一个梳理。你不用照抄格式，关键是理解每个章节的写作目的。

7.1 目录结构与写作重点

以常见的本科论文格式为例：

• 第一章 绪论：写清楚研究背景和意义，你用的是哪个技术栈、为什么选它，以及国内外研究述评。这一章不需要写很多页，但要把项目定位讲清楚。
• 第二章 相关技术介绍：Spring、SpringMVC、MyBatis、Vue、MySQL 的发展简况和特性。重点是你为什么选择它们，不要变成名词百科。答辩时老师大概率会从这一章里找一两个概念追问。
• 第三章 需求分析：可行性分析、功能需求分析、用例图、角色分析。尽可能画好用例图，这是这一章最容易拿分的部分。
• 第四章 系统设计：总体架构（前后端分离结构图）、功能模块设计、数据库概念结构设计（E-R 图）、逻辑结构设计（数据表字段表）。
• 第五章 系统实现：按模块写实现过程，配上核心代码段和系统截图。建议代码量不宜太长，保留关键逻辑；截图要清晰，不要截半个页面。
• 第六章 系统测试：测试环境（JDK 版本、MySQL 版本、浏览器）、测试用例表格、测试结果分析。
• 第七章 总结与展望：你的工作量总结、不足之处。这个部分写得越具体越真实，比如"订单超卖场景尚未做并发压力测试"，比写着"系统存在不足，将在未来改进"这种空话要好得多。

7.2 测试用例怎么写才不像是编的

测试用例是论文里最容易看穿"注水"的部分。你可以这样组织：

写实际操作步骤时要具体到"在哪个页面输入什么内容、点击什么按钮"，老师一看就知道你不是编的。另外，测试用例最好和你代码里修复过的问题对应上，比如"复测：并发预约场景库存不为负"这类用例，能体现你的调试经验和工程素养。

7.3 论文里图和表的使用比例

图纸尽量控制在"一张图表说明一个观点"的范围。E-R 图、功能结构图、用例图、系统架构图这四类建议都要有；数据库表结构中，每张核心表挑主要字段列进去，不用把所有表的字段都堆到正文里。我个人的做法是，核心表（用户、景区、订单、评价）在正文展示完整的字段设计，其他辅助表放在附录里。这样论文既清爽，又能看出你对数据库设计的主导感。

8. 我自己做这类项目时总结的三条经验

最后说一下我多轮摸索下来的体会，也是答辩和评审时老师问得最多的几个问题的应对参考。

经验一：把"自主推广"贯穿到自己项目的每一个地方。 很多同学做完的项目"能跑但不知道好在哪"，往往是因为它缺少了题目特有的味道。景区推广平台区别于"景区售票系统"的核心，就是运营方能否在前台控制展示效果、推广内容、推荐顺序。你在设计数据表、功能菜单、页面布局时，都把"能不能自主配置和推广"这个点放在前面考虑，项目的完成度会立刻上一个台阶。

经验二：演示流程做到能不看代码顺畅跑通。 我习惯在交付前自己彩排三遍：第一遍按正常用户流程走——注册、浏览、收藏、下单、查看订单；第二遍用管理员账号走后端流程——接一个景区、发一篇动态、调一个推荐位、处理一个订单；第三遍专门点那些"容易翻车的角落"——比如提交空表单、重复提交、翻页后操作按钮，看看有没有控制不住报错的情况。这三遍走完，答辩现场出问题的概率会小很多。

经验三：涉及安全的代码宁可多花时间也值得做。 学生项目的通病是权限校验只做前端隐藏按钮，后端接口裸奔。你只要在 Controller 层用拦截器校验登录态、在管理端接口再做一轮角色校验即可，这些代码量不大，但它能体现系统工程意识，比堆功能更能给老师留下正面印象。

到这个节点，你的系统从需求文档一路走到可演示、可部署、可答辩的完整形态。接下来的工作量完全是体力活——把代码再归置一下、把文档图补一补，然后稳着节奏走一遍流程。景区自主推广平台这个题目，只要抓住"内容自主可控、推广位可配置、多角色分权"这三个核心设计，论文和代码都不会跑偏。