今年轮到我做2026年的毕业设计，选题阶段翻了一圈，最后落在了“基于SSM与Vue的旅游服务与管理系统的设计与实现”上。说句实话，“SSM+Vue旅游系统”这个题目在网上已经不算新鲜，但它恰好覆盖了计算机专业本科阶段最核心的知识点：后端整合、数据库建模、前端交互、权限控制、事务与并发。我花了两个多月把程序写完、论文也交上去，整个过程踩坑不少，但也正因为是这种“常见题”，做通了之后，很多同类管理系统都可以照猫画虎地套用。这篇内容想写给准备拿类似题目做毕设的同学：题目怎么拆需求、数据库怎么建模、SSM后端哪些模块最容易写崩、Vue前端怎么跟接口对齐、论文又要怎么和程序一一对应。看完不敢说你能直接拿高分，但至少能少走一半弯路。

1. 从题目到需求：旅游系统到底要装下哪些功能

1.1 为什么“旅游”这个业务方向适合做毕业设计

旅游服务与管理系统的业务对象非常清楚：用户、旅游线路、订单、评价、后台管理。整个链路天然覆盖了CRUD、分页、搜索、排序、权限、事务、统计报表这些毕业设计里必须出现的功能点。你不需要去猜业务规则，旅游平台的玩法大家都很熟悉：游客登录后浏览线路，按城市和类型筛选，选中某条线路后下单，支付成功后产生订单，玩完了还能评价。这一套流程从头到尾就是一个完整的企业级管理系统缩影，写论文的时候需求分析和系统设计都有充足素材。

这种题目翻车的点也正好在这里：太容易贪功能。我见过有同学一开始就要做支付、地图、短信验证、在线聊天、推荐算法，最后三周过去了一个模块都没写利索。我的建议是，毕业设计追求的是“业务闭环完整”而不是“功能数量惊人”。我做这套系统时定下的原则是：注册登录、线路浏览、多条件搜索、下单支付模拟、个人收藏与评价、管理端全量数据维护、统计图表，这些做完就够撑起一篇合格的论文和一次十分钟的答辩。多余的功能可以在论文“系统展望”里写，但不要把半成品放进程序里让老师点出破绽。

准备线路数据也要提前想好。我的做法是手工构造了四十多条模拟线路，城市字段用“西北某古城”“南方某海岛”“北方滨海城市”这一类虚构地名，价格区间从几百到几千元不等，库存数量和分类信息保持一致性。这样列表页筛选、详情页展示、下单扣库存都不会出现前后矛盾。千万不要为了省事直接把真实平台上的地名和价格原样抄进去，老师们对这类数据非常敏感，而且后续答辩时如果被追问数据来源，很难解释清楚。

1.2 角色与功能清单：一套系统两个入口

任何管理系统都绕不开角色。我在论文里把用户划分为两类：普通游客和系统管理员，整个系统采用同一套代码、同一个数据库，通过登录用户的角色字段来控制能看到的菜单和能调用的接口。

普通游客端包括：注册登录、旅游线路浏览、按城市/分类/价格区间搜索、线路详情查看、收藏线路、下单并模拟支付、查看个人订单列表、对已完成的线路发布评价、修改个人资料。管理员端包括：用户管理（禁用或启用账号）、线路管理（新增、编辑、上下架、删除）、分类管理、订单管理（查看所有订单、标记发货或完成、处理取消）、评论审核、基于时间的订单量和热门线路统计报表。

功能列表不要写得模糊。论文的需求分析阶段，我针对每个功能都写了一句“业务描述”，比如“游客在订单列表中可以查看待支付、已支付、已完成、已取消四种状态，并对待支付订单执行取消操作”。这种描述越具体，后期画用例图、写测试用例就越省力。凡是功能清单里写了的功能，程序里就必须能跑通；凡是你程序里偷偷做了的“隐藏功能”，论文里也最好有对应说明，否则答辩时很容易被老师挑“文档和实现不一致”。

1.3 技术选型的真实理由，而不是单纯跟风

后端选SSM，在我们学校是最稳妥的，因为课程设计和社会实践项目基本都是Spring + SpringMVC + MyBatis这套组合。选它有一个很现实的好处：论文里可以单独用一节来讲解三个框架的分工——Spring负责Bean管理和事务声明，SpringMVC负责请求路由和参数绑定，MyBatis负责SQL的编写和数据实体映射。这种“能讲出原理”的技术栈，比稀里糊涂用了一个又不会解释的框架要加分。如果选Spring Boot，程序是好写了，但答辩时如果被问到“自动配置原理”或者“为什么不用SSM”，反而更容易露怯，因为Boot帮你屏蔽了太多细节。

前端选Vue2配Element UI，原因很朴素：网上成熟教程最多、踩坑成本最低。如果你现在开始做，可以直接用Vue3配Element Plus，写法上差异不算大，但组件库的名称、表单校验方法、路由模式这些细节都要重新适应。数据库用MySQL，版本选5.7或8.0都行，只要注意连接驱动版本匹配。部署环境就是传统的Tomcat，前端打包后放到webapps目录下，后端以WAR包形式跑在同一个Tomcat里，这样整个系统就是同源同域的，不需要处理跨域和Session共享问题。这个部署方案看起来老土，但它稳定，也最容易在论文里讲清楚。

2. 数据库与公共约定：把E-R图和分页规则一次想清楚

2.1 核心表结构的设计取舍

旅游服务与管理系统的数据库不需要太多表，但每一张表的字段都要能支撑起功能。我最终落地的表一共六张：用户表、线路分类表、旅游线路表、订单表、评论表、收藏表。这里没有做购物车表，因为旅游线路下订单时是直接提交单条线路的，订单表里记录线路ID、数量和成交价格即可，不需要把“购物车”这个中间状态引进来增加复杂度。

用户表主要字段包括id、username、password、nickname、phone、role、status、create_time。密码不需要用MD5加密的话就明文存？不行，论文里容易被质疑安全性。我的做法是前端把密码交给后端，后端用MD5加盐后再入库，代码实现并不复杂，但论文里的“系统安全性设计”一节就有内容可写。线路表是核心资产，字段包括id、name、city、category_id、price、stock、days、intro、detail、cover_url、status、create_time，其中city和category_id会被频繁查询，我在两个字段上建立了普通索引，用于支撑搜索筛选。

订单表和用户表、线路表之间全部使用逻辑外键，不建物理外键。这个决定我特意在论文里解释了：逻辑外键可以让分页查询和动态SQL拼接更灵活，删除线路时不会因为级联约束报错；另外在数据量大的场景下物理外键对写入性能有影响，很多互联网系统也都是不用物理外键的。答辩时老师如果问“为什么不用外键”，这个回答基本是标准答案。订单表里设计了order_no、user_id、route_id、quantity、total_amount、status、create_time、pay_time；评论表包含route_id、user_id、content、score、status、create_time；收藏表是一个简单的二元关联表，只需要user_id和route_id。

2.2 测试数据造不好，列表页就会露馅

造数据这一步看起来不起眼，实际很影响开发效率。第一次做的时候我对线路表数据不重视，随便填了二十条记录，结果列表页一翻页就出现图片缺失、价格排序混乱、城市筛选后出现空分类等一堆问题。后来花了一个多小时把线路数据重新整理了一遍：每条线路都有对应的封面图，图片放到前端项目的静态目录中；价格字段统一保留两位小数；库存字段统一设置20到99之间的整数；分类保证和分类表强一致。

还有一件常被忽略的事：创建时间和更新时间。第六张表里如果都有create_time字段，那么在列表里按时间倒序排序、在后台统计按天分组，才能有真实的数据效果。我在造线路数据时把create_time随机分布在过去九十天内，这样管理端“近90天新增线路数”的折线图看起来非常自然。

2.3 统一返回体和分页约定，前后端才真正“对齐”

后端接口如果有一天没一个统一返回格式，前端写起来会非常痛苦。我的Controller层所有接口都返回Result对象，结构是code、msg、data三个字段，成功时code为200，业务校验不通过时code对应自定义的401、403、404、500等状态。前端axios的响应拦截器只需要判断code等于200就进入业务逻辑，否则弹出msg内容并把用户踢回登录页。这样的好处是，新增一个接口根本不用为前端设计返回格式，每个方法的返回类型都是Result，统一又整洁。

分页我直接用PageHelper，前端统一传pageNum和pageSize两个参数。查询线路列表和订单列表时，Controller返回的data字段是PageInfo对象，里面有total、pageNum、list等字段，前端表格组件直接绑定即可。这里要提前跟你们说的是PageHelper的用法非常死板，startPage方法必须紧跟第一条需要分页的查询语句，两者之间不能插入其他数据库查询操作，否则分页就悄悄失效了——这个坑我在后端章节里还会再讲一次。

3. SSM后端的三场硬仗：鉴权、搜索、订单状态

3.1 登录鉴权：不用JWT也能说清楚的拦截器方案

网上各种“SSM+Vue”项目动辄带你引入JWT和Redis，但对毕业设计来说复杂度偏高。工程上完全可以把用户登录后的信息放进Session，并设置一个自定义请求头标识当前登录用户。后端通过拦截器统一校验Session里的用户对象是否存在，不存在就返回401。这个方案不需要引入额外依赖，代码量只有几十行，却足以在论文里作为权限控制的实现方案。

我的拦截器代码如下：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 从请求头中拿自定义标识 String userToken = request.getHeader("token"); HttpSession session = request.getSession(); Object user = session.getAttribute("loginUser_" + userToken); if (user == null) { response.setContentType("application/json;charset=utf-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录或登录已过期\"}"); return false; } // 把用户信息重新放入request，方便Controller直接使用 request.setAttribute("loginUser", user); return true; } }

在SpringMVC配置文件中，拦截器要对静态资源放行，比如.js、.css、图片目录，否则前端加载会白屏。登录接口、注册接口也必须放行。后台管理端的所有接口单独上一套拦截器，校验登录用户角色是否为admin。这样权限控制分成了两层：游客层面用登录拦截器，管理员层面用角色判断，逻辑很清楚。

这里要特别注意一处实际开发中容易踩的坑：当你把Vue前端和SSM后端部署在同一个Tomcat时一切都好说，但如果你开发时前端跑在npm的8081端口、后端跑在Tomcat的8080端口，它们之间跨域，axios请求必须开启withCredentials，浏览器才会把后端Set-Cookie的Session ID保存下来。我为了省这个麻烦，开发时直接在前端的vue.config.js里配置了代理，生产环境又保持同域部署，全程没有碰跨域Session的传递问题，答辩时老师问“你是怎么解决跨域的”，也能从代理和同域部署两个层面给出解释。

3.2 多条件搜索：MyBatis动态SQL是核心技术点

旅游线路的搜索要求比较常见：关键词、城市、分类、价格区间、排序方式，这些条件可能一个都不选，也可能全选。如果为每种组合各写一条SQL，接口就会爆炸。正确做法是使用MyBatis的动态SQL标签拼接条件。

我写的Mapper如下：

<select id="searchRoutes" resultType="com.travel.entity.Route"> select * from route <where> <if test="keyword != null and keyword != ''"> and (name like concat('%', #{keyword}, '%') or intro like concat('%', #{keyword}, '%')) </if> <if test="city != null and city != ''"> and city = #{city} </if> <if test="categoryId != null"> and category_id = #{categoryId} </if> <if test="minPrice != null and maxPrice != null"> and price between #{minPrice} and #{maxPrice} </if> and status = 1 </where> <choose> <when test="sort == 'priceAsc'"> order by price asc </when> <when test="sort == 'priceDesc'"> order by price desc </when> <otherwise> order by create_time desc </otherwise> </choose> </select>

注意keyword的模糊查询一定要用concat拼接，而不是写成"like '%${keyword}%'"。前者是预处理方式，可以防SQL注入；后者把参数直接拼进SQL，一旦用户在搜索框输入特殊字符，轻则查询出错，重则被构造攻击语句。论文的“系统安全设计”里把这一点写进去，会比较有说服力。

这条SQL配合前面建好的索引，搜索性能足够应对毕设数据量。答辩时如果老师问“怎么优化搜索”，先说索引，再说动态SQL避免全表条件失控，最后可以补一句“如果线路数据达到百万级，可以使用Elasticsearch做全文检索或者引入Redis缓存热点线路，这部分我放在后续扩展里”。

3.3 订单状态机与防超卖：事务必须放在Service层

订单模块是整个系统的业务核心，因为每个操作都不只是改一行数据。下订单的流程是：先校验线路存在且上下架状态正常，再检查库存是否足够，然后生成唯一订单号并写入订单表，最后执行库存扣减。这四个步骤任何一步失败，前面已经做的修改都要回滚，所以必须放到一个事务方法里。

关键实现如下：

@Service public class OrderServiceImpl implements OrderService { @Override @Transactional public Long createOrder(Integer userId, Integer routeId, Integer quantity) { Route route = routeMapper.selectById(routeId); if (route == null || route.getStatus() != 1) { throw new RuntimeException("线路不存在或已下架"); } // 条件更新扣库存，返回影响行数来判断是否超卖 int rows = routeMapper.decreaseStock(routeId, quantity, route.getStock()); if (rows == 0) { throw new RuntimeException("库存不足"); } String orderNo = generateOrderNo(userId); Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setRouteId(routeId); order.setQuantity(quantity); order.setTotalAmount(route.getPrice() * quantity); order.setStatus(0); order.setCreateTime(new Date()); orderMapper.insert(order); return order.getId(); } }

这里有两个细节值得单独说一下。第一个，库存更新用的是条件更新的写法：update route set stock = stock - #{quantity} where id = #{id} and stock >= #{quantity}，这条SQL本身就能防止并发下的超卖问题，因为数据库的行锁会保证两次更新串行执行，后一个事务会因为影响行数为0而判断库存不足。第二个，订单号是时间戳加用户ID再加三位随机数拼出来的，在并发场景下重复概率极低，不需要依赖数据库自增主键来生成业务编号。

我把状态定义成四个：0待支付、1已支付、2已完成、3已取消。支付模拟就是把这个订单的状态从0改成1，同时更新pay_time字段。订单列表页根据当前状态显示不同的操作按钮：待支付可以取消，已支付可以提醒商家发货，已完成可以评价。这套状态机在各种管理系统中都可以复用，论文里我会画一张订单状态流转图，把“状态、触发事件、目标状态”列成表格，看起来非常专业。

事务注解不要加在Controller层，这是很多初学者容易搞错的。Controller层只是接收参数和返回结果，事务本身属于Service层的业务边界，加在Controller上会让事务范围过大，还可能因为代理机制失效导致事务不生效。我在做这个项目时特意把Service接口和实现类分开，实现类的方法上标注@Transactional，这样Spring的声明式事务判断和代理都处于正常的路径上。

4. Vue前端：路由、菜单、跨域代理，以及和接口的默契

4.1 目录结构与管理/游客端路由划分

Vue这边的开发思路是：先用Vue CLI初始化项目，装好Element UI、Axios、Vue Router，然后把页面按角色分目录管理。我采用的目录是src/views/user存放游客端页面，src/views/admin存放管理端页面，src/api目录下按模块拆分接口文件。Element UI的组件引入是最大一块重复代码，我按文档说明在mian.js里全量注册了组件，虽然打包体积大一些，但开箱即用，不用每个页面单独导入。

路由设计上，我并没有把游客端和管理端拆成两个完全独立的框架，而是放在同一个布局里，通过路由meta里的roles字段来设置访问条件。例如/admin/user这个路由的meta里写了roles: ['admin']，普通游客就算知道路径也进不去；前端路由守卫会先判断登录状态，再判断角色。游客端首页、线路详情、订单列表这些路由则不限制角色。这个设计的代码量不大，但论文里画权限分配表、用例图时非常方便。

菜单的控制是根据登录用户角色动态渲染的。登录成功后后端返回用户信息，包含role字段，前端把它存到localStorage里，侧边栏组件根据role过滤自身配置的菜单数组。游客看到的菜单只有“首页、线路列表、我的收藏、我的订单”；管理员看到的是“用户管理、线路管理、分类管理、订单管理、评论审核、统计报表”。注意这种做法只是隐藏和展示层面的控制，真正防止未授权访问还是要靠后端的拦截器，我在论文和答辩中都会特别强调这一点。

4.2 Axios封装、代理和请求头携带登录标识

前端所有请求都走同一个Axios实例，我在src/utils/request.js里做了统一封装。baseURL设成/api，请求拦截器里从localStorage读取token字段并塞进请求头；响应拦截器判断后端返回的code，如果等于200就正常返回data，否则用Element UI的Message组件弹出错误信息，遇到401就清理本地登录状态并跳转登录页。这样做之后，页面里调用接口的逻辑就非常干净，不用在每个组件里写错误提示。

import axios from 'axios' import { Message } from 'element-ui' import router from '../router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['token'] = token } return config }) service.interceptors.response.use(response => { const res = response.data if (res.code === 200) { return res } Message({ message: res.msg || '请求失败', type: 'error' }) if (res.code === 401) { router.push('/login') } return Promise.reject(new Error(res.msg)) }) export default service

开发环境下的跨域是用vue.config.js的devServer.proxy解决的，把/api开头的请求全部转发到http://localhost:8080/travel。之所以要加一个travel前缀，是因为我的后端WAR包部署名是travel，不过这不重要，以你自己项目的部署名为准。生产环境我在打包后把dist目录里的文件直接拷贝到Tomcat的webapps/ROOT目录，这样前后端共享同一个端口和上下文路径，不存在跨域问题，也就不需要配置CORS过滤器了。

线上部署后的一个坑是页面刷新404。Vue Router如果使用history模式，直接访问或刷新管理端地址时Tomcat找不到对应的物理路径，就会跳404。最简单有效的解决办法是把路由模式改成hash，或者在后端加一个forward到index.html的控制器。我图省事直接用hash模式，虽然地址栏里带个#号，但毕设演示完全没关系。

4.3 页面落地：表格、搜索表单、分页关联的细节

后端接口设计得再干净，前端页面写得不顺手，开发体验还是很糟。我用Element UI的el-table和el-pagination组件配合接口，把搜索条件、当前页码、每页条数放在同一个data对象中，每次点击搜索或翻页都带着这套参数请求后端。有个细节是el-pagination的current-change事件绑定一个方法，方法里先更新pageNum，再重新调用加载函数；size-change事件则要重置pageNum为1，因为切换每页条数后继续停留在原来的页码会导致列表越界。

游客端首页的线路卡片用el-card挂载循环，城市和分类的筛选下拉框，选项都是打开页面时从后端接口拉取的，不是写死在代码里的。这样新增分类或城市数据后，搜索条件会自动带上新选项，论文的系统测试里也勉强能算一个“动态性”的测试点。

下单页面是另一个容易写错的地方。因为Element UI的日期选择器默认传给后端的值是JavaScript时间戳，数据库字段是datetime类型，两者对不上时报错非常难排查。我后来在日期相关组件上都加了value-format="yyyy-MM-dd"，提交的字符串就正常入库了。凡是表单里有日期字段的项目，这一条基本都能用上。

5. 论文与程序如何互相咬合：结构、图表和演示顺序

5.1 论文章节安排与字数控制

论文不是程序的事务文档，它有固定的表达套路。我最终用的结构是：绪论、需求分析、系统设计、系统实现、系统测试、总结与展望。字数分配大概是这样：绪论1500字，主要写背景意义和国内外研究现状；需求分析2500字，包含用例图、功能性需求和非功能性需求；系统设计3000字，包含系统架构图、功能模块划分、数据库设计；系统实现4000字，每个核心功能一个小节，配图和代码；系统测试1500字，用测试用例表格加测试结果；总结展望800字。这个体量在绝大多数本科毕设里是够用的。

写系统实现章节时，一定要做到“图对应程序、程序对应功能、功能对应需求”。比如我写订单实现时，先截了一张用户下单页面的运行截图，再贴一段下单接口的核心代码，然后描述这段代码如何完成了库存校验和事务回滚。论文里的小标题也要避开“系统实现”这种泛泛的写法，我拆分成了“游客注册登录模块实现”“旅游线路搜索模块实现”“在线下单与支付模块实现”“后台管理模块实现”，让整篇论文的目录看起来有层次感。

5.2 用例图、E-R图和界面截图的规范做法

用例图我用绘图工具画了两张：游客用例图和管理员用例图。游客的用例包括注册、登录、浏览线路、搜索筛选、查看详情、收藏、下单支付、评价；管理员的用例包括登录、用户管理、线路管理、分类管理、订单管理、评论审核、查看统计报表。E-R图则是把六张表画成矩形，表之间用菱形连接，标注“收藏”“下单”“评论”三种关系，连接线两侧标好1和n的基数。

界面截图是很多人口头说重要但最后做得一塌糊涂的地方。我的建议是：每个功能模块截2到3张关键页面，截之前把浏览器地址栏里的localhost信息码掉，控制台如果开着也清理掉，图片统一按“图4-1游客注册界面”这种格式命名。论文里的代码不要贴整个Service类，只截取核心方法或者关键代码片段，每段控制在15到20行以内，并且代码后面一定要跟一两句解释，说明这段代码解决的问题是什么。这些细节指导老师一眼就能看出你是自己动手做的还是拼凑的。

5.3 防止大段摘抄拉高重复率，以及答辩演示的素材准备

需求分析章节最容易重复率爆表，因为网上模板都是“随着经济发展和人们生活水平提高……”这种句子。我的办法是把空洞的背景描述改成具体技术问题描述，比如“传统线下报名方式效率低，游客无法在线上比较线路价格，管理员手工维护线路信息容易出现差错”。这样既把问题写清楚了，又和自己的设计目标产生了对应关系。

答辩演示这一天，你大概率只有五到八分钟。我准备的演示路线是：注册账号登录，到首页浏览线路列表，用一个城市筛选条件展示搜索结果，进入详情页下单并支付模拟，再看订单状态变成已支付，切换管理员账号审核评论，最后打开统计报表展示近期订单趋势。每一步操作对应论文里一个章节，老师顺着你的演示就能建立整篇论文的结构感。另外把后端日志窗口提前打开，演示时指给老师看接口调用记录，会显得你对整个系统非常诚实且了如指掌。

6. 从开发到答辩的真实复盘：坑、问法和时间线

6.1 开发中最常见的六类问题清单

其中PageHelper这个坑我想再多说一句，它不只是“顺序”问题，在同一个方法里有两条查询语句时，很多人会习惯性先查别的表做校验，再执行目标分页查询，结果分页就失效果。最稳妥的写法是startPage紧接着PageHelper查询，需要校验的数据放到分页查询之后再去查，或者用单独的Provider方法查询。

6.2 关于SSM和Vue，答辩老师最常问的几个问题

“为什么用SSM而不直接用Spring Boot”，这个问题基本每场都会被问到。我的回答是：学校课程体系以SSM为主，使用SSM能完整展示Spring的IOC和AOP机制、SpringMVC的请求映射过程以及MyBatis中SQL的写法，整个框架整合过程是手动的；如果使用Spring Boot，很多配置会被自动完成，反而难以体现对框架底层整合的理解。这样回答下来既诚实，又落到了实际能力展示上。

“数据库为什么不用外键”和“订单并发怎么处理”在前面几节已经给了思路。老师还爱问“系统后续怎么扩展成真实可运营的旅游平台”，回答时不要只说大词，要落到具体模块上：登录鉴权可以升级成JWT加Redis，支付模块接入微信或支付宝SDK，搜索查询替换为Elasticsearch，图片走阿里云OSS，线路数据引入真实景区API。挑两到三点说就够了，说明你有工程视野即可。

还有一道题容易翻车：“你的系统里哪些地方体现出安全设计？”如果你做过密码加盐、SQL用预编译、拦截器防未授权访问，这些都是很好的论点，但前提是你真做了，千万别只靠嘴说。

6.3 给2026届的时间排期建议

我把这两个月的节奏拆成八个星期，每周末都做一个阶段复盘。第一周把需求清单、数据表结构和页面原型完全定死；第二、三周集中做后端，顺序是用户模块、线路模块、搜索模块；第四周做订单、评价和后台统计；第五周进入前端开发和接口联调；第六周集中修bug、补边界情况，比如用户没登录时收藏是否会跳转登录、库存不足提交订单会不会报错；第七周开始写论文，此时程序里所有运行截图都已经随手保存好了；第八周做PPT、录演示视频、准备答辩台词。

程序完成度直接决定论文质量，这个结论在我身上得到了验证。前期我每天花一点时间记录“今天解决了什么问题”，积累了二十多条问题清单，后来整理进论文的“系统实现难点”和“系统测试”章节，整篇论文的素材都是现成的。给你的建议就是，开发过程里所有踩过的坑都记下来，哪怕一句也行，这比最后一周抱着代码憋论文有效得多。

如果让我重新把这个项目做一遍，我会在第一天就先把所有表结构和接口返回格式定死，然后每天截图存档。这个小习惯能让你在最后写论文时完全不慌，也祝你能把这套SSM+Vue旅游服务与管理系统从简历一路带进答辩现场，顺利过关。