企业官网建设流程全解析

每年到这个时间点，论坛和群里总会有大量"求推荐一个好做的毕设题目"的帖子。我的建议一直很明确：与其去追那些名字花哨、听着高大上的题目，不如老老实实把一个业务场景清晰、技术栈主流的系统做扎实。旅游景点管理系统就是这样一个被严重低估的经典选择。它看似简单，但仔细拆开看，用户端、管理端、订单流转、数据统计、权限控制，该有的模块一个不少，技术深度完全够用，而且和日常生活场景贴合，演示的时候评委一听就懂。这篇文章就围绕基于 Java + SpringBoot 框架的旅游景点管理系统的设计过程，把选题逻辑、技术选型、数据库设计、核心代码实现、踩坑经历和答辩准备完整讲一遍。无论你是刚开始选题，还是已经建了工程正在写代码，这篇内容都能直接拿走参考。

1. 为什么这个题目年年热门，却依然值得做

1.1 题目的真实定位：不是"简单"，是"边界清晰"

很多人一听到"旅游景点管理系统"就觉得太普通，好像谁都能做。但恰恰是这个"普通"，让它在毕设场景里成了最稳妥的选择。毕业设计的时间有限，通常只有两到三个月，这中间还要上课、找工作、准备考研复试。如果一个题目的业务边界过于开放，比如"智能推荐系统研究"，你会发现需求越聊越多，算法越做越深，最后连核心流程都没跑通就要交初稿了。

旅游系统的业务边界是天然清晰的：前台用户能看景点、搜景点、下单订票；后台管理员能维护景点信息、审核订单、查看统计报表。两边角色清楚，权限划分自然，数据库表很容易设计成第三范式。更重要的是，这个场景谁都去过景区、买过票、看过攻略，做需求分析的时候不需要去访谈真实用户，自己就能把用例列全。对评委来说，他们不需要花五分钟听你解释业务背景，直接看功能就能判断系统做得怎么样。

1.2 它踩中了毕设评审的所有关注点

毕设答辩的评分维度其实很固定：系统能不能跑起来、功能完不完整、代码结构清不清楚、技术是不是主流、工作量够不够。旅游景点管理系统在这几个维度上都天然占优势。

先说工作量。一个做完整的系统，光核心业务表就能有六七张：用户表、景点表、景点分类表、订单表、评论表、收藏表、公告表。每张表背后对应着增删改查页面，加上搜索、分页、排序、状态流转，前后端交互接口轻松超过二十个，工作量绝对饱满。

再说技术覆盖度。SpringBoot 负责后端框架，MyBatis-Plus 操作数据库，MySQL 存数据，前端用 Vue + ElementUI 或者服务端模板渲染都行，登录鉴权可以用 JWT 或者 Session，图片用本地存储或者对象存储，统计报表用 ECharts 画图。这些东西组合在一起，就是一个标准的现代 Web 开发技术栈，每一个点评委都认识，也都愿意看到。

1.3 什么样的人适合选这个题目

我接触过的选这类题目的同学大概有三类。第一类是基础一般、想把主要精力放在把系统做完整做稳定上的；第二类是已经有工作 Offer，毕设只想高分通过不想再折腾的；第三类是准备用这个项目当作面试项目经验写在简历上的。第三类需要额外注意，如果想把旅游系统写进简历，就必须在代码规范、接口设计、亮点细节上做到能拿得出手的程度，而不是停留在"能跑"的水平。

反过来，如果你的兴趣在算法、AI、中间件源码这类深水区，那这个题目可能委屈你了，选题方向上应该优先考虑导师的研究课题或者大厂实习的方向。这个权衡，越早想清楚越好。

2. 技术栈搭配：SpringBoot 组合到底怎么定

2.1 为什么生态默认选 SpringBoot 而不是 Spring + SpringMVC

现在做 Java Web 毕设，SpringBoot 已经是事实上的默认选项。我见过一些同学还在用传统的 SSM（Spring + SpringMVC + MyBatis）手写一堆 XML 配置，集成一个页面模板要改五个配置文件，启动还经常因为包扫描路径写错报出一串英文异常。这个年代真的不建议再这么干了。

SpringBoot 解决的最大痛点就是"配置地狱"。它通过自动配置把大量样板配置变成默认行为，内嵌 Tomcat，启动就是main方法跑起来，不需要额外部署 WAR 包。对毕设来说，这意味着你多出来的时间可以全部花在业务代码上，而不是和 XML 配置死磕。更重要的是，招聘市场上 SpringBoot 的接受度明显高于传统 SSM 配置方式，很多面试官看到简历里的"熟悉 SpringBoot 自动配置原理"会比"熟练使用 SSM"更感兴趣。

下面是我给这个项目的技术栈建议：

2.2 前端方案：前后端分离还是模板渲染

这里要做一个选择，这个选择会直接影响你的开发节奏和答辩效果。

第一种方案是前后端完全分离，前端用 Vue 脚手架独立工程，通过 Axios 调后端接口。优点是企业主流开发模式，接口文档、跨域处理、部署方式都能体验一遍，简历上写"前后端分离项目"是加分项。缺点是你至少还要掌握 npm、Vite、Vue Router、Pinia 或 Vuex 这一套工具链，前端页面的工作量会明显增加。

第二种方案是使用 SpringBoot 的模板引擎 Thymeleaf，后端渲染 HTML，一个工程搞定所有内容。优点是开发链路短，不用处理跨域，部署只需要打一个 JAR 包，适合时间紧张的同学。缺点是前后端耦合紧密，页面交互体验会粗糙一些，答辩时技术含金量不如分离方案。

我的经验是：如果你已经有前端基础或者愿意花一周时间补 Vue 基础，就选前后端分离，这个技术组合在答辩和面试时都更有说服力。如果时间实在不够、英语四六级还压着没考完，那老老实实选 Thymeleaf，把后端逻辑做扎实，一样能拿良好以上的成绩。

2.3 版本选型和环境坑位：先统一再动手

版本问题我多说一句，因为每年都有人在这里浪费两三天。SpringBoot 2.7.x 是目前最适合毕设的稳定版本，不要一上来就用 SpringBoot 3.x。原因很简单：3.x 基于 Jakarta EE，很多老教程里的javax包名要改成jakarta，如果你照着网上文章复制代码，会遇到大量导入报错。MyBatis-Plus 也要选和 SpringBoot 2.7 兼容的版本，我用的3.5.3.1版本实测没有问题。

JDK 建议用 1.8 或者 11，不要用 17 以上的新版，除非你非常确定所有依赖都兼容。MySQL 用 8.0，连接驱动用mysql-connector-java 8.0.33。开发工具就用 IDEA，社区版就够用。这些固定下来之后，新建工程和跑第一个接口的速度会快很多。我自己第一次踩过 SpringBoot 3.x 的坑，换了 2.7 之后整个世界安静了。

3. 从功能清单到数据表：先把系统骨架搭稳

3.1 功能拆解：用户端和管理端各做什么

我习惯在写任何代码前，先把功能清单列成表格，确认没有遗漏再建表。一个标准的旅游景点管理系统，功能可以拆成两大块。

用户端：

• 注册登录：支持用户名密码注册、修改密码
• 景点浏览：首页展示推荐景点、分类筛选、关键词搜索
• 景点详情：图文介绍、门票价格、开放时间、评分、评论列表
• 在线预订：选择日期和数量，生成订单，待支付状态
• 我的订单：查看订单、取消订单、评论订单对应的景点
• 个人中心：修改资料、查看收藏列表

管理端：

• 管理员登录
• 景点管理：添加、编辑、上下架、多图上传
• 分类管理：维护景点分类和标签
• 订单管理：查看所有订单、按状态筛选、标记已消费
• 用户管理：禁用/启用用户、重置密码
• 评论管理：审核评论、删除违规评论
• 公告管理：发布和更新公告
• 数据统计：访问量趋势、订单量趋势、热门景点排行

列完这份清单你就能发现，这个系统的核心业务流是"用户浏览景点 -> 提交预订 -> 管理员处理 -> 用户评价"，所有功能都围绕这条主线展开。演示的时候只要按这条线走，评委的思维就会非常流畅。

3.2 数据库设计：六张核心表的关系与字段

数据库表设计是整个系统的基础，表结构设计不好，后面的代码写起来处处别扭。下面是我建议的核心表结构，你可以在建表时直接参考。

景点表t_scenic：

• id主键
• name景点名称
• category_id分类ID，关联分类表
• cover_image封面图片URL
• detail_images详情图，可以用JSON数组字符串存多张图的路径
• description景点介绍，长文本
• price门票价格，用decimal(10,2)
• open_time/close_time开放/关闭时间
• address所在地
• status状态，1上架 0下架
• view_count浏览量
• create_time/update_time

订单表t_order：

• id订单号
• order_no业务订单号，唯一索引
• user_id下单用户ID
• scenic_id景点ID
• ticket_count购票数量
• total_amount总金额
• visit_date游玩日期
• status状态：0待支付 1已支付 2已取消 3已完成 4已退款
• create_time下单时间

用户表t_user：

• id、username、password（BCrypt加密）、nickname、phone、avatar、status、create_time

评论表t_comment：

• id、user_id、scenic_id、content、rating（1-5分）、status、create_time

分类表t_category：

• id、name、sort、status

公告表t_notice：

• id、title、content、create_time

表设计有几个细节需要注意。第一个，金额字段永远不要用float和double，用decimal，否则会出现 19.99 显示成 19.989999 这类浮点误差问题。第二个，order_no要设计成唯一索引，并且由代码生成而不是数据库自增，这样方便后续对接支付回调。第三个，数据库字段类型建议和 Bean 属性一一对应，不要为了省事全部用varchar，时间该用datetime就用，小数字段用tinyint语义更清晰。

3.3 为什么用 MyBatis-Plus 而不是手写 SQL

很多网课还在教传统 MyBatis，每个实体类对应一个 Mapper XML 文件，里面手写一堆resultMap和简单的 CRUD SQL。这套东西能玩，但效率确实低。MyBatis-Plus 在 MyBatis 基础上做了大量增强，单表 CRUD 根本不用写 SQL，继承一个BaseMapper<T>接口，selectById、selectList、insert、updateById直接就有。分页也不用自己写LIMIT和COUNT，引入分页插件配置好后，Page<T>直接返回分页结果。

它还有两个对毕设非常友好的特性。一个是条件构造器LambdaQueryWrapper，复杂查询可以像写链式调用一样组合条件，不用手工拼接 SQL 字符串，可读性高很多。另一个是内置的代码生成器，配置好数据库地址和表名之后，自动生成实体类、Mapper、Service、Controller，省掉大量机械劳动。

我见过有同学听到"MyBatis-Plus 是别人封装好的"就不敢用，担心答辩被问原理。完全不用担心，你只要回答清楚"它底层仍然是 MyBatis 框架，通过封装通用方法减少重复劳动，核心 SQL 仍然可以手写掌控"就够了。答辩问得多的反而是你的业务逻辑，不会抓着 ORM 框架追问。

4. 关键功能实现：查询、下单、鉴权、统计四个核心点拆开讲

功能模块很多，我不打算全部流水账式地过一遍，只挑四个决定系统质量的核心点，把实现思路和关键代码讲透。这四个点做明白了，剩下的功能照葫芦画瓢就行。

4.1 景点搜索与分页：一个能应对绝大多数查询场景的范例

景点列表页是最常用的页面，支持按关键词模糊搜索、按分类筛选、按价格区间筛选、按评分排序。这段逻辑是所有查询功能的模板，值得认真写。

public Result pageScenic(ScenicQueryDTO dto) { Page<Scenic> page = new Page<>(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapper<Scenic> wrapper = new LambdaQueryWrapper<>(); // 关键词模糊匹配名称或简介 if (StringUtils.hasText(dto.getKeyword())) { wrapper.and(w -> w.like(Scenic::getName, dto.getKeyword()) .or().like(Scenic::getDescription, dto.getKeyword())); } // 分类筛选 if (dto.getCategoryId() != null) { wrapper.eq(Scenic::getCategoryId, dto.getCategoryId()); } // 价格区间筛选 if (dto.getMinPrice() != null) { wrapper.ge(Scenic::getPrice, dto.getMinPrice()); } if (dto.getMaxPrice() != null) { wrapper.le(Scenic::getPrice, dto.getMaxPrice()); } // 只看上架景点 wrapper.eq(Scenic::getStatus, 1); // 排序规则：综合、价格升序、评分降序、浏览量降序 if ("priceAsc".equals(dto.getSort())) { wrapper.orderByAsc(Scenic::getPrice); } else if ("priceDesc".equals(dto.getSort())) { wrapper.orderByDesc(Scenic::getPrice); } else if ("ratingDesc".equals(dto.getSort())) { wrapper.orderByDesc(Scenic::getRating); } else { wrapper.orderByDesc(Scenic::getViewCount); } Page<Scenic> result = scenicMapper.selectPage(page, wrapper); return Result.success(result); }

这里有一个容易被忽略的细节：当关键词字段同时匹配名称和简介时，like条件要用and(w -> w.like(...).or().like(...))包起来，否则后续的eq条件和它拼接时，SQL 的优先级会出问题，查出来一堆不是你想要的数据。这种隐蔽的逻辑错误，代码走查很难发现，但用户一操作就暴露了。

另外我建议把查询参数封装成 DTO 类，而不是在 Controller 方法里写七八个@RequestParam。这样接口签名会非常干净，后续扩展筛选条件只需要在 DTO 里加字段。垃圾代码和好代码的差距，往往就体现在这种细节上。

4.2 下单流程：前端防重复，后端幂等

订单功能是系统的核心业务，也是最容易出逻辑错误的地方。典型的坑是：用户在景点详情页连续点了两下"立即预订"，如果前端没有做按钮防重复，后端也没有任何幂等保护，就会插入两条一模一样的订单。

正确的做法是前后端双重防护。前端在点击提交后，用loading状态将按钮置灰；后端通过order_no的唯一索引兜底。生成order_no的规则，我用的方案是日期+随机数+用户ID后四位，例如20250610143012 + 三位随机数 + 用户ID后四位，虽然简单，但在并发量不大的毕设场景下足够保证唯一性。

创建订单和锁定库存不能用拆开的两个事务，必须在同一个事务方法里完成。下面这个例子展示了核心逻辑：

@Transactional(rollbackFor = Exception.class) public Order createOrder(OrderCreateDTO dto, Long userId) { // 1. 校验景点是否上架 Scenic scenic = scenicMapper.selectById(dto.getScenicId()); if (scenic == null || scenic.getStatus() != 1) { throw new BusinessException("景点不存在或已下架"); } // 2. 计算金额 BigDecimal amount = scenic.getPrice() .multiply(BigDecimal.valueOf(dto.getTicketCount())); // 3. 生成唯一订单号 String orderNo = generateOrderNo(userId); // 4. 构建订单并插入 Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setScenicId(scenic.getId()); order.setTicketCount(dto.getTicketCount()); order.setTotalAmount(amount); order.setVisitDate(dto.getVisitDate()); order.setStatus(0); orderMapper.insert(order); return order; }

@Transactional注解必须写rollbackFor = Exception.class，因为默认情况下 Spring 只在抛出RuntimeException时回滚，如果方法里抛出的是受检异常，事务不会回滚，数据就错乱了。这个知识点也是答辩喜欢问的，提前记牢。

下单之后就是支付流程。毕设不需要真的接支付接口，我建议把支付模拟成"点击支付按钮 -> 直接修改状态为已支付"，页面文案标明"模拟支付"即可。如果你想让项目更完整，可以加一个"支付页面倒计时、超时自动取消"的小功能，成本不高但演示效果很好。

4.3 登录鉴权：JWT 方案的设计与拦截器落地

管理端和用户端都需要登录鉴权，我选择的是 JWT 方案。整体思路是：用户登录成功后，后端签发一个带过期时间的 token，前端在后续请求的请求头Authorization里携带它，后端通过拦截器校验 token 的有效性并解析出用户信息。

JWT 的核心价值是无状态，服务端不需要保存 session，这对前后端分离的部署模式非常友好。具体实现步骤可以拆成三段。第一段是登录接口，验证用户名密码后生成 token；第二段是拦截器，继承HandlerInterceptor，在preHandle里取请求头、校验签名、把用户 ID 存入request属性；第三段是在 Controller 层通过工具方法取出当前用户 ID。整个过程代码量不大，但能体现你对 Web 安全的了解。

public String generateToken(Long userId, String role) { Map<String, Object> claims = new HashMap<>(); claims.put("userId", userId); claims.put("role", role); return Jwts.builder() .setClaims(claims) .setSubject(String.valueOf(userId)) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

密码存储务必使用 BCrypt 加密，不能明文存储。Spring Security 的BCryptPasswordEncoder可以直接拿来用，不要自己写 MD5。答辩时如果被问到"为什么不用 MD5"，你可以回答：BCrypt 内置随机盐，相同密码每次加密结果不同，能有效抵御彩虹表攻击。这样回答既专业又有深度。

4.4 数据统计：让系统拥有"智能化"的感觉

标题里提到了"智能旅游景点管理平台"，智能化不能只停留在字面，数据统计页面是体现平台价值的核心载体。我的建议是做一个专门的管理端统计页，展示三块内容：近 7 天订单量趋势折线图、景点销量 Top10 柱状图、各分类占比饼图。

数据统计不建议在前端做，也不建议每打开一次页面就全表扫描。最简单的实践是写统计 SQL 让数据库聚合，比如统计各景点销量：

SELECT s.id, s.name, COUNT(o.id) AS order_count, SUM(o.total_amount) AS total_amount FROM t_scenic s LEFT JOIN t_order o ON o.scenic_id = s.id AND o.status = 1 GROUP BY s.id, s.name ORDER BY order_count DESC LIMIT 10

这里用了LEFT JOIN而不是INNER JOIN，目的是把那些还没有被下单的景点也查出来，不然销量图永远只显示热销景点，下架景点就完全看不到了。这种分析型 SQL 的细节，往往能体现候选人对业务数据的理解深度。

统计接口返回的数据格式设计成 ECharts 直接可用的结构，比如List<Map<String, Object>>，键是name和value。前端拿到之后直接赋值给图表的dataset，不用做二次加工。如果你完全不会前端画图，用后端接口配合 ECharts 的官方示例改一改就够了，数据结构和示例基本一致。

5. 毕设最容易踩的坑：我写订单模块时的三个真实翻车现场

写了这么多年代码，也帮不少同学排查过毕设问题，这一章把旅游系统项目里最常见的坑集中讲一遍。这些坑单独拿出来都不大，但每一个都能让你卡住一两天。

5.1 日期时间格式化与市区问题——前端显示永远差 8 小时

旅游系统的订单要记录下单时间，景点要开放时间，评论要有发布时间，几乎到处都要和时间打交道。最常见的翻车现场是：前端页面上显示的时间和数据库存的时间差了 8 小时。

原因很简单：MySQL 连接串里如果没有配置时区参数，默认使用服务器时区，而本机运行的 JVM 使用本地时区，两者不一致就会发生时间错位。解决办法是在数据库连接 URL 上显式加上serverTimezone=Asia/Shanghai，同时把 JDBC 驱动和数据库版本匹配好。另外，SpringBoot 在对Date类型做 JSON 序列化时，如果不指定格式，会输出默认时间戳或者奇怪的格式，前端展示就会一团乱麻。

解决办法是在实体类的日期字段上使用@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")注解。这个注解能保证序列化输出是北京时间的标准格式。下面的配置建议直接抄：

spring.datasource.url=jdbc:mysql://localhost:3306/travel_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai spring.jackson.date-format=yyyy-MM-dd HH:mm:ss spring.jackson.time-zone=GMT+8

这两个配置缺一个，日期展示上就容易出问题。省下来的排查时间拿去打磨业务逻辑，不香吗？

5.2 上传图片后刷新页面图片丢失

景点管理系统天然需要处理图片，封面图、详情图、用户头像，全部绕不开文件上传。很多同学的实现方式是：把图片保存到项目工程目录下的static/upload文件夹，数据库里存相对路径，本地启动访问正常。但只要换了机器、打了新包或者用 IDEA 重新编译，图片就全部 404 了。

原因在于这个上传路径是 IDEA 编译输出目录下的临时目录，每次clean或重新构建就会被清空重置。正确的做法是把上传路径配置到操作系统的一个固定目录，比如 Windows 下用D:/travel-upload/，Linux 下用/data/travel-upload/，然后通过一个虚拟映射让 Web 服务能访问到这个外部目录。

SpringBoot 中可以做如下配置：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath = "file:D:/travel-upload/"; registry.addResourceHandler("/upload/**") .addResourceLocations(uploadPath); } }

这样配置之后，访问http://localhost:8080/upload/xxx.jpg就能映射到外部目录中的文件，即使重新编译也不会丢失。答辩时如果老师问"除了本地存储还有什么方案"，可以顺带提一句生产环境一般用对象存储，比如云存储服务，这样显得你了解过真实部署方案。

5.3 分页插件失效，所有数据一次性查出来

如果你用 MyBatis-Plus，分页功能依赖分页插件的配置。我见过好几个人代码里写了Page对象，但查询结果始终是全量数据，原因就是忘记注册分页插件。

即使你使用的 MyBatis-Plus 版本较新，也仍然需要显式注册。正确的配置是新建一个配置类：

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

分页插件不生效的另一个隐蔽原因是数据库方言不匹配，比如数据库明明是 MySQL，你配置的却是DbType.OTHER。遇到分页异常时，先检查这条配置，八成问题就出在这里。用日志插件打开 SQL 输出，能看到正确的分页语句长什么样，对比一下就知道哪里不对了。

6. 演示与答辩准备：让评委三分钟看懂你的系统

很多同学代码写完了，但答辩现场手忙脚乱，页面切来切去不知道讲什么，最后评委只记住了两个报错弹窗。演示和答辩本质上都是"讲故事"，你要把评委当成第一次用这个系统的用户，按照一条最优路径带他们走完整个流程。

6.1 准备一份有"真实感"的演示数据

我特别强调数据库里不要只放三条测试数据就上台。你要放足够多、足够真实的模拟数据：景点至少准备 15 到 20 个，覆盖自然风光、历史古迹、主题乐园、博物馆等不同分类；每个景点配 4 到 5 张清晰的大图，介绍文字写得像旅游网站一样通顺；订单数据要有不同状态、不同日期分布，这样统计页面画出来的图表才好看。

演示数据的准备不是浪费时间，这是让评委产生信任感的关键。想象一下，一个景点管理系统的首页只有三个景点，其中一张图还是默认占位图，评委第一反应就是"这个项目没有认真做"。反过来，数据足够丰富，评委打开首页会自然地被内容吸引，接下来你说什么他都听得进去。

我有个经验：到知名旅游网站上收集景点的真实名称、地址、介绍，然后稍微改动一下名称再录入，既保证了演示时的熟悉感，又避免了版权问题。价格数据不用完全真实，按 30、50、80、120 这样的整数设置就好了，方便演示时心算金额。

6.2 设计一条"黄金演示路径"

不要从登录页开始讲，没人想看注册登录。从首页推荐景点开始，切换到景点详情，模拟用户搜索和筛选，找到目标景点后演示下单流程。支付完成后展示"我的订单"状态变化，然后切到管理端，演示管理员如何查看和处理刚下的订单。最后打开统计页面，把刚才的操作产生的数据变化展示出来，整个闭环就完整了。

这条路径的核心逻辑是"业务闭环"：用户侧产生数据，管理侧响应数据，统计侧汇总数据。评委跟着你的思路走，三分钟就能建立起对系统的整体认知，后期提问也会集中在他们留意的几个点上，问的问题会更可预测。

演示过程中务必提前关掉无关应用，清理浏览器缓存。我见过太多人现场演示因为微信弹窗、IDE 调试输出、代理插件干扰而翻车。把演示用的浏览器单独开一个无痕窗口，提前登录好管理端账号，这些细节能极大降低紧张程度。

6.3 高频答辩问题清单与回答要点

答辩提问虽然随机，但万变不离其宗。我把旅游系统相关的常见问题整理成一份清单，你提前准备好答案，基本可以在答辩环节游刃有余。

• 为什么选 SpringBoot？答：简化配置、自动装配、内嵌服务器、生态成熟，适合快速开发和维护。
• JWT 和 Session 有什么区别？答：JWT 无状态、适合分布式，Session 有状态、需要存储在服务器端。
• 数据库为什么这么设计？答：从业务实体出发拆表，避免冗余，订单和景点分开保证数据一致性。
• 超级管理员和普通用户怎么区分？答：角色字段区分，登录后按角色控制接口访问权限。
• 如果并发量变大怎么办？答：加缓存（如 Redis）、读写分离、消息队列削峰。
• 安全问题怎么考虑？答：BCrypt 加密密码、参数校验、拦截器统一鉴权、SQL 预编译防注入。

这些问题回答的时候不需要长篇大论，关键词清晰、逻辑顺畅比内容多更重要。比如问数据库设计，你说"把订单和景点独立成表是为了让每个实体的生命周期清晰，订单状态流转不污染景点数据"就点到为止了，语速放慢，比背书效果好得多。

6.4 论文和源码的一致性：最后一个容易被扣分的地方

最后提醒一件很多人忽略的事：论文里的架构图、数据库设计图、核心代码片段，必须和实际项目完全一致。不少同学写完代码后再补论文，脑子里想的和实际写的对不上，画出来的部署图多了一个模块，贴出来的代码缩进全乱，评委随便翻一下就觉得态度有问题。

论文里放核心代码时，挑一段最能体现业务逻辑的，比如下单事务那段、拦截器那段、查询统计那段，不要贴整页的 Controller 实现。标注好注释，缩进对齐，答辩时如果老师翻到这一页，你还能顺着讲一遍，这就是加分项。论文里的运行界面截图建议用统一分辨率的窗口截图，不要一会儿全屏一会儿小窗，技术文档的观感很重要。

最后分享一点实际的感受

做毕设这件事，说到底是"在规定时间内用技术解决一个完整问题"的训练。旅游景点管理系统的好处在于，它没有那么多不可控的因素，你的精力可以集中在最核心的工程能力上。我在做类似项目的过程里学到最重要的一件事是：先画好边界，再动手写代码。功能边界想清楚、表结构定明白、接口名统一好，后面的开发就是往框架里填内容。反过来，如果一开始就急着写代码，边写边加需求、边写边改表，最后一定会陷入无休止的返工。

如果你正准备做这个题目，我的建议是：花两到三天把需求文档和数据库设计定下来，中间不要跳过，然后严格按照设计去实现。等你写到订单模块的时候，会体会到前面稳扎稳打带来的顺畅感。愿你这篇毕设能顺利过关，答辩时也能从容地把你的系统讲清楚。