基于Web的旅游社交分享系统：Java毕设选题与实现全攻略

每年这个时候，都会有一批计算机专业的同学开始为毕设选题挠头。作为一个前后帮人看过不知道多少份Java毕设代码的老兵，我太清楚大家想要什么了：题目不能太旧，否则答辩老师看一眼就失去兴趣；技术栈不能太偏，否则遇到问题连查都查不到；工作量得适中，既不能简单到像课程设计，又不能复杂到自己hold不住；最好还能带上完整的源码和文档，因为很多人是边学边做的。今天要聊的这个“基于Web的旅游社交分享系统”，恰好就是把这几个诉求平衡得比较好的一个选题。它既有Web项目该有的技术含量，又有明确的应用场景，从开题报告到答辩演示都能说得清楚，属于那种“老师听着觉得有意义，自己做着也能落地”的题目。

这个系统说白了，就是把社交元素和旅游内容结合起来：用户可以注册登录，浏览别人发布的景点攻略、旅行日记，自己对感兴趣的内容点赞、收藏、评论，还可以关注其他旅行达人，从而形成一个以旅游为纽带的内容社区。它和我们熟悉的那些笔记类、点评类应用是同一个路子，但业务模型更清爽，功能边界更清晰，特别适合作为本科毕业设计的载体。这篇文章我会从选题思路、技术选型、数据库设计、核心模块实现，到一路调试踩过的坑，完完整整捋一遍。不管你是已经选了类似题目，还是正在犹豫要不要选，这都能当一份靠谱的参考地图。

1. 为什么我推荐这个选题

1.1 毕设题目的三个硬指标

先说说选题的大逻辑。我带过的学生里，挂掉或者做得痛苦的，往往不是在技术上栽跟头，而是死在选题阶段。毕设不是越难越好，也不是越新越好，它要同时满足三个硬指标：工作量可感知、技术栈有得讲、业务逻辑能自洽。

“基于Web的旅游社交分享系统”在这三点上都很稳。工作量上，它天然包含用户模块、内容模块、互动模块、社交关系模块，随便一拆就是四五个大功能块，画出来的功能架构图至少是三层结构，不会让人觉得单薄。技术栈上，Java方向的经典组合Spring Boot + MyBatis/MyBatis-Plus + MySQL可以完整覆盖后端，前端用Vue或纯Thymeleaf都行，整个链路里既有CRUD，又有权限控制，还有文件上传这样的经典场景，答辩时每个点都能展开聊。业务逻辑上，旅游社交这个场景足够具体，用户、攻略、游记、关注、评论、收藏这些实体之间的关系自然成立，不存在那种为了做系统而硬凑功能的尴尬感。

另外一个很现实的好处是，这个方向网上资料足够多，哪怕是零基础起步，从零到一写出一个能跑的版本，参考代码也找得到。这里顺便多说一句，写毕设最忌讳的是选一个网上几乎找不到资料的方向，那不是彰显个性，那是给自己挖坑。

1.2 从需求分析里看出题人的意图

理解一个毕设项目，不能只看它叫什么名字，要看它背后完整的需求结构。如果你拿到的是类似“社交媒体生活娱乐分享平台”“旅游社交分享系统”这种题目，其实出题人想让你做的事情就三层：第一层是基础的登录注册和用户信息管理，第二层是旅游内容的生产与展示，也就是发布攻略、查看景点信息、浏览图文列表，第三层是社交互动，也就是点赞、收藏、评论、关注用户。三层加在一起，就构成一个用户能“逛”起来的闭环。

我建议拿到题目的第一件事，不是急着写代码，而是把这三层需求画成一张业务流程图，哪怕用纸笔都行。目标用户是谁（旅行者、内容创作者）、他们要做什么（记录行程、找攻略、互动）、系统要怎么承接（内容列表、详情页、个人中心），这一串想明白了，后面一切模块划分都是水到渠成的事。很多同学做完一个项目问起来逻辑支支吾吾，其实就是第一层需求分析没过关。

1.3 这个项目能写进简历的亮点

除了毕业本身，毕设项目还是求职时项目经验的重要来源。旅游社交分享系统虽然不算新概念，但胜在完整，它是典型的内容社区模型，和真实互联网产品高度一致。你可以理直气壮地在简历上写：负责设计并实现了XXX旅游分享平台，包括用户认证、内容发布、互动评论、关注Feed流等核心模块，采用JWT保障接口安全，使用Redis缓存热点数据等。

这些表述每一个都能在面试时展开讲出来，比如JWT为什么选它不用Session，缓存怎么保证一致性，Feed流是怎么推的。如果你的毕设能做到这个颗粒度，面试官不会觉得你只是在交作业，他会觉得你具备基本的工程思维能力。这一点，比题目本身“新不新”重要得多。

2. 技术架构与核心设计思路

2.1 技术选型的原则与落地组合

先说说我为什么推荐一套看上去“不够炫”但非常稳的Java技术栈。说实话，每年都有学生问我能不能用Spring Cloud、能不能上RabbitMQ、能不能搞微服务。我的回答很直接：毕设的核心是完整性和说服力，不是技术堆砌。你用微服务拆五个服务，结果连分布式事务都讲不明白，答辩老师追问两个问题就露馅了，反而扣分。

主流的单人毕设最佳实践是单体应用，但“单体”不意味着“简陋”。我推荐的基础组合是：

• 后端：Spring Boot 2.7.x + MyBatis-Plus 3.5.x + Spring MVC
• 数据库：MySQL 8.0（InnoDB引擎，utf8mb4字符集）
• 缓存：Redis 6.x（用于验证码、热点数据、Token黑名单，可选但建议有）
• 前端：Vue 3 + Element Plus + Axios，或服务端渲染的Thymeleaf
• 权限方案：Spring Security + JWT，或使用拦截器 + JWT的轻量方案
• 文件存储：本地磁盘路径存储或OSS（本地路径即可）

这套组合的核心优势在于，每一层都是行业内使用率最高的方案，遇到的问题基本都有现成答案，调试起来不会卡死在冷门知识上。同时MyBatis-Plus真的是检索型CRUD利器，单表操作几乎不用写SQL，能让你的注意力集中在业务逻辑而不是重复的数据库操作上。

2.2 前后端分离还是服务端渲染

这个问题每个选Web方向的同学都会纠结一次。我建议分情况考虑：如果你前端基础薄弱，平时只写过静态页面，那就老老实实选服务端渲染，用Thymeleaf写页面，后端返回完整的HTML，省去了跨域和联调的麻烦；如果你已经会用Vue或者愿意花两周学一下，那就走前后端分离，因为这套模式下API接口的概念非常清晰，答辩展示时也更有“工程感”。

我自己带学生做这类毕设，如果时间相对紧张，我会推荐一个折中策略：核心功能（登录、内容发布、列表页）走前后端分离，用Vue + Element Plus搭一套管理后台；而面向游客的浏览页可以简单一些。这样既不用把全部页面都做成动态渲染，又能体现前后端协同的能力。不过如果你用的是我下面要讲的单体架构，全部用Thymeleaf实现也完全没毛病，工作量并不会少太多。

2.3 模块划分与分层架构

整个系统按业务可以拆成这几个模块：

• 用户模块：注册、登录、个人信息维护、头像上传
• 内容模块：景点信息管理、攻略/游记发布、图文内容展示
• 社交模块：关注/取关、粉丝列表、关注用户的内容Feed流
• 互动模块：点赞、收藏、评论、评论回复
• 系统模块：轮播图管理、公告管理、后台数据概览（可选）

分层架构上就是标准的Controller-Service-Mapper三层，中间夹一层DTO/VO做数据封装。这里有一个经常被忽视的细节：很多同学喜欢直接把数据库实体类返回给前端，一是不安全（比如密码字段直接暴露），二是前后端字段不一致时非常被动。我的习惯是每个接口都定义清晰的VO，哪怕字段一样也照写，这是养成工程习惯的好机会。

2.4 安全与权限设计要点

Web系统最怕答辩被问“你的接口安全怎么做”。对毕设而言，不需要做到企业级，但基本的防线要有。推荐做法是JWT + Spring Boot拦截器。用户登录成功后，后端签发一个有效期（比如2小时）的Token返回给前端，前端在后续请求的Header里带着Authorization: Bearer xxx，拦截器负责校验Token，并把当前用户信息放入ThreadLocal供后续业务使用。

这里需要提醒的是，JWT本身不复杂，复杂的是密钥管理和过期续期策略。毕设只要做到“登录才能发内容/点赞/关注，游客只能看”就足够了。同时另一个常用技巧是，对密码使用BCrypt加密，绝对不要明文存储。这两点做到，答辩时安全这块就基本挑不出大毛病。

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

3.1 数据表设计的总思路

数据库设计是整个系统最重要的地基。以旅游社交分享系统为例，核心表需要覆盖用户、内容、关系、互动四类。具体来说，我通常会设计这么几张表：

• user：用户表，字段包括id, username, password, nickname, avatar, gender, phone, email, introduction, status, create_time等
• attraction：景点表，字段包括id, name, cover_image, summary, province, city, address, detail, view_count, create_time等
• travel_note：攻略/游记表，字段包括id, user_id, attraction_id, title, content, cover_image, status, like_count, collect_count, view_count, create_time等
• user_follow：关注关系表，字段包括id, user_id, follow_user_id, create_time
• note_like：点赞表，字段包括id, note_id, user_id, create_time
• note_collect：收藏表，字段包括id, note_id, user_id, create_time
• comment：评论表，字段包括id, note_id, user_id, content, parent_id, create_time

这里有一个重要的设计心得：互动数据（点赞、收藏）不要单独存一个计数然后在每次操作时+1或-1，而是同时建一张明细表和在外键上冗余一个计数器字段。明细表负责判断用户今天是否已经点过赞，冗余计数负责列表页展示。两者配合才能做到既能查状态又能显示数量，否则每次列表渲染都要count一次，数据一多页面就慢得不行。

3.2 关键表结构与设计原因

以travel_note为例，贴一下我常用的建表SQL，你可以参考着根据自己的项目修改：

sql复制CREATE TABLE `travel_note` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `user_id` bigint(20) NOT NULL COMMENT '发布者ID',
  `attraction_id` bigint(20) DEFAULT NULL COMMENT '关联景点ID',
  `title` varchar(100) NOT NULL COMMENT '标题',
  `content` longtext COMMENT '正文内容',
  `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图URL',
  `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态：0-草稿 1-发布 2-删除',
  `like_count` int(11) NOT NULL DEFAULT '0' COMMENT '点赞数',
  `collect_count` int(11) NOT NULL DEFAULT '0' COMMENT '收藏数',
  `view_count` int(11) NOT NULL DEFAULT '0' COMMENT '浏览数',
  `create_time` datetime NOT NULL COMMENT '创建时间',
  `update_time` datetime DEFAULT NULL COMMENT '更新时间',
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_attraction_id` (`attraction_id`),
  KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='攻略/游记表';

这张表的设计有几个小心思值得讲一讲。第一，status字段做成逻辑删除而不是物理删除，好处是用户删了动态之后管理员还能看到痕迹，数据安全性更好；第二，like_count和collect_count是冗余字段，通过定时或实时更新来保持与明细表一致；第三，索引上要建create_time，因为列表页最常见的排序是“最新发布”，没有这个索引数据量稍大就会走全表排序。这些看似不起眼的细节，恰恰是答辩时能拿出来讲的加分项。

再看关注表user_follow，它是最简单的自关联模型之一：

sql复制CREATE TABLE `user_follow` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL COMMENT '用户ID（主动关注者）',
  `follow_user_id` bigint(20) NOT NULL COMMENT '被关注者ID',
  `create_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_user_follow` (`user_id`,`follow_user_id`),
  KEY `idx_follow_user` (`follow_user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户关注关系表';

唯一索引uk_user_follow非常关键，它从数据库层面保证了同一个人不会重复关注同一个人，配合服务端的“是否已关注”判断，能有效防止脏数据。我见过不少半途而废的项目，问题就出在没加唯一约束，导致用户重复取关关注时数据乱套。这张表送给有缘人，照抄即可。

3.3 关联查询与列表页性能

列表页常见的做法是联表查出用户昵称、头像、标题、封面、点赞数这些字段。如果直接join user表，数据量几百条时其实感觉不到差异，但为了养成好习惯，我建议在列表查询SQL中只查出必要的字段，不做select *，同时把“用户昵称”和“用户头像”作为冗余字段缓存起来，或者用一次批量查询后在内存中组装。

MyBatis-Plus的Page分页插件就能搞定大部分列表分页需求，配合LambdaQueryWrapper写条件非常爽快。需要留意的是，分页插件要记得配置拦截器PaginationInnerInterceptor，很多同学导了包没配拦截器，结果分页失效，这就是纯粗心造成的坑了。这类细节我在后面调试部分会展开说。

4. 核心业务模块的实现要点

4.1 注册登录：从Session换到JWT

登录注册是所有Web项目的入口，也是最容易写出“年代感”的模块。以前很多教程教的是Session + Cookie方案，服务端存session，前端带cookie。但到了前后端分离的时代，这个方案要处理跨域携带Cookie的问题，比较折腾。所以我更推荐JWT方案，更符合接口化的思维。

具体流程是：前端提交用户名和密码，后端用AuthenticationManager校验，成功后用Jwts.builder()生成Token，设置过期时间，返回给前端。前端在Axios的请求拦截器里从localStorage取出Token塞到Header里。后端写一个拦截器，从Header解析Token，校验通过就放行，并解析出userId放到RequestContextHolder里。

这里给出一个核心的JWT工具类片段：

java复制public class JwtUtil {
    private static final String SECRET_KEY = "your-256-bit-secret";
    private static final long EXPIRE_TIME = 1000 * 60 * 60 * 2; // 2小时

    public static String createToken(Long userId, String username) {
        return Jwts.builder()
                .setSubject(username)
                .claim("userId", userId)
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME))
                .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
                .compact();
    }

    public static Claims parseToken(String token) {
        return Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody();
    }
}

这个工具类里有两点值得注意。第一，密钥SECRET_KEY在实际项目中绝对不能写在代码里，至少也要写在配置文件或者环境变量中。毕设阶段可以写在配置里，但答辩时你要能说出“这里用配置中心管理会更安全”，这就是亮点。第二，JWT解析时如果过期会抛ExpiredJwtException，要catch住并返回友好的提示给前端，引导用户重新登录，而不是直接甩一个500错误。

4.2 内容发布：文件上传与富文本的取舍

内容发布模块是整个系统的重头戏。攻略和游记不能只有标题和文字，还得有封面图。图片上传这块，很多教程一上来就让你配OSS或者七牛云，但对毕设来说，把图片保存到本地上传目录就够了，关键是把访问路径映射做好。

Spring Boot的静态资源映射只需要加一个配置类：

java复制@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        // 将 /upload/** 映射到本地磁盘路径
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:D:/dev/upload/");
    }
}

同时，需要在application.yml里限制上传文件大小：

yaml复制spring:
  servlet:
    multipart:
      max-file-size: 5MB
      max-request-size: 10MB

注意一个问题：很多同学第一次上传文件后发现图片能存进去但页面死活打不开，多半就是路径映射没配对，或者上传到了项目编译后的临时target目录里，项目一重启文件就丢了，这是典型的毕设调试大坑。一定要把上传路径放到项目之外的一个固定目录，不要用relative path，用绝对路径。

内容正文我这里建议用简单文本加换行格式，不要强行上富文本编辑器。富文本的HTML保存后会有XSS风险，而且图片base64乱飞会导致数据库字段爆炸。如果确实需要排版，推荐用支持Markdown语法的编辑器，存储时保留原Markdown，展示时前端解析。这是一条很实用的避坑指南。

4.3 点赞收藏：幂等性与状态联动

点赞和收藏是一对孪生功能，我放在一起讲。核心要解决的问题就是两个：重复点击怎么处理，状态和数量怎么保持一致。

先说方案。当用户点击点赞按钮时，前端把noteId传给后端，后端执行一个事务：

1. 查询note_like表里有没有记录（userId + noteId）
2. 如果没有，插入一条点赞记录，同时travel_note表的like_count加1
3. 如果有，删除点赞记录，同时like_count减1

这其实就是一种“反范式”的设计模式，用冗余计数换取读取性能。为了让这个“同时”真正成立，两处操作必须在同一个@Transactional方法里。MySQL默认的RR隔离级别下，这个方案不存在并发安全问题，唯一要小心的是要在代码里先判断再更新，别把“插入记录”和“更新计数”拆到两个事务里，否则中途报错就会出现状态不一致。

另外接口设计时建议返回一个Map或者VO，包含两个字段：liked（当前用户是否已点赞）和likeCount（最新点赞数）。这样前端不用自己猜状态，一次请求就能把按钮状态和数字都刷新了。

4.4 关注与Feed流：别把需求复杂化

社交模块中，“关注后能看到对方发布的攻略”这个需求在毕设里十分常见，很多同学第一次听到“Feed流”这个词就开始慌。其实毕设阶段完全不需要上复杂的推拉结合架构，最简单的实现方式就是拉模式。

实现思路是：查询用户关注的ID列表（select follow_user_id from user_follow where user_id = 当前用户），然后查询攻略表时加上in (那些关注人的ID)条件，再按发布时间倒序分页。SQL类似这样：

sql复制SELECT * FROM travel_note
WHERE user_id IN (SELECT follow_user_id FROM user_follow WHERE user_id = #{currentUserId})
AND status = 1
ORDER BY create_time DESC
LIMIT #{offset}, #{pageSize}

这段SQL在数据量几千条时跑得飞快，完全够用。不要给自己加戏去设计发件箱收件箱，那是大厂海量用户场景才需要考虑的东西。能把“关注的人发布的攻略”完整地展示在信息流里，已经超过八成毕设的水平了，而且逻辑清晰、答辩好讲。

4.5 评论：两级结构最合理

评论模块也容易出问题，主要是层级设计易过度。我的建议是只做两级评论：一级评论直接挂在攻略下面，二级评论作为一级评论的回复，回复中通过parent_id字段关联。也就是说，comment表里note_id是一级归属，parent_id为0表示顶级评论，不为0表示回复某条评论。查询时先查所有顶级评论，再根据顶级评论id批量查它的子回复，组装成树形结构返回前端。

避免使用无限极评论树的原因很简单：开发复杂度成倍上升，而后端递归组装对新手很不友好，一旦出错很难调试，而且对毕设场景来说，无限极评论完全不必要。答辩时老师问起来，你可以回答“多余二级评论采用interactive合并展示，避免过深的层级损耗阅读体验”，这就把一个省事的设计讲成了产品决策。

5. 常见问题与调试排查实录

5.1 跨域问题：前后端分离的第一道坎

做前后端分离的同学一定会遇到跨域报错：浏览器控制台红字Access-Control-Allow-Origin。这不是后端逻辑错了，是浏览器的同源策略拦了请求。解决办法很简单，在Spring Boot里写一个跨域配置类：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

注意allowedOriginPatterns("*")和allowCredentials(true)要组合使用，否则某些浏览器会报错。这段配置放在config包下面就能生效，它解决的是开发环境跨域，生产环境部署在同域下就不需要了。

5.2 JWT拦截器放行与ThreadLocal用户信息

登录模块写好后，最容易出现的一个bug是：登录接口自己也被拦截器拦了，导致前端一调用登录接口就401。根本原因是拦截器配置里忘了放行/api/user/login和/api/user/register。我在代码里推荐用白名单方式：

java复制registry.addInterceptor(jwtInterceptor)
        .addPathPatterns("/api/**")
        .excludePathPatterns("/api/user/login", "/api/user/register", "/api/attraction/**", "/api/note/list", "/api/note/detail/**");

另外，在拦截器里解析完Token后，我习惯把userId放到RequestContextHolder的工具类中，供后续Service层随时取用：

java复制public class UserContext {
    private static final ThreadLocal<Long> USER_ID = new ThreadLocal<>();

    public static void setUserId(Long userId) { USER_ID.set(userId); }
    public static Long getUserId() { return USER_ID.get(); }
    public static void clear() { USER_ID.remove(); }
}

用ThreadLocal存当前请求的登录用户，是很多Java项目实际使用的方式。要注意的是，在拦截器的afterCompletion方法里记得调用UserContext.clear()，否则线程池复用会串号，这个bug属于隐形杀手，非常恶心但极容易排查出来。

5.3 MyBatis-Plus分页失效与字段映射

分页失效是MyBatis-Plus新手几乎必踩的坑。现象是查出来的结果集没有按LIMIT截断，而是全表数据。原因通常是没配置分页插件。解决方法是添加一个配置类：

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

还有字段映射问题，如果数据库字段是create_time下划线风格，而Java属性是createTime驼峰风格，默认情况下MyBatis-Plus是能自动映射的，前提是application.yml里没有把map-underscore-to-camel-case设置成false。如果查出来这个字段是null，先检查配置，不要一上来就怀疑SQL写错了。

5.4 文件上传后访问404

这个问题我在前文提过一次，这里展开讲。404的常见原因有三个：第一，上传路径用的相对路径，项目位置一变文件就找不到了；第二，静态资源映射的addResourceLocations路径结尾没有加/；第三，文件存进去了但数据库里存的是绝对路径，前端直接用路径访问时拼接错误。我的习惯是，数据库里只存相对路径/upload/xxx.jpg，前端拼接服务器地址访问。这样即使将来换服务器，只要文件搬过去，路径不用改。

如果用了Tomcat部署，还要注意一个细节：server.servlet.context-path配置会影响静态资源的访问前缀，建议要么不配，要么统一在请求地址里带上这个前缀。

5.5 列表页慢：先看SQL再看代码

做过一个小优化很有意思，有段时间列表页接口要1.5秒才能回来，一开始以为是代码效率问题，后来打开SQL日志一看，发现每次列表查询都执行了N+1条SQL——先查出10条攻略，然后又循环查10次用户信息。解决方法是把N+1合并成两条SQL，先从攻略表查出列表和一个去重的userId集合，再用selectBatchIds批量查出用户信息，最后在内存中用Map组装。这一处优化把这个接口从1.5秒压到了120毫秒左右，体验完全变了。做优化时一定要先看SQL日志和慢查询，不要一上来就改代码。

5.6 部署时数据库连不上

很多同学本地运行好好的，一部署到服务器就报错Communications link failure。原因大多是MySQL没开远程访问，或者云服务器的安全组没放通3306端口。如果你是在云服务器上部署，需要用Navicat之类的工具先在本地测试能不能远程连上数据库，排除网络问题后再查Java配置。另外购买服务器时如果预装了宝塔面板，要记得MySQL的root用户默认可能只允许localhost登录，需要新建一个远程用户并授权。

部署这块我的建议是：如果只是交个毕设，不用折腾Docker，直接把Spring Boot项目打成jar包，用nohup java -jar xxx.jar &跑起来就行，前端打包后扔到Nginx的html目录下，再把接口的/api反向代理到后端地址。这套流程半小时能搞定，现场演示时也比本机运行更有说服力。

5.7 常见问题速查表

把上面提到的坑和对应的排查手段整理成一张表格，方便你开发时对照：

6. 答辩准备与项目扩展方向

6.1 演示路径要提前设计

答辩演示是有技巧的，不要一上来就点开一堆页面乱逛。我的建议是设计一条“故事线”：先以游客身份浏览首页景点和热门攻略，再注册一个新账号登录，发布一条自己的旅游攻略（最好提前准备好图片和文字），然后演示点赞、收藏、评论，最后演示关注另一个用户后Feed流里出现对方的新内容。每个环节提前想好要说的话术，控制在8分钟以内讲完，这比现场随意点要强太多。

6.2 答辩时老师最喜欢问的几个问题

根据我陪学生答辩的经验，这个项目老师大概率会问到这几个问题：

• 为什么用JWT而不用Session？JWT的无状态特性适合前后端分离，服务端不需要保存会话状态。
• 点赞数量的并发安全怎么保证？数据库事务加唯一索引，同一时刻同一个人只能有一条点赞记录。
• 如果用户量变大，Feed流怎么优化？从拉模式演进到读扩散或写扩散，配合Redis缓存热点数据。
• 你上传的文件存哪了？本地存储，生产环境应该上对象存储并做CDN加速。

这些问题都不算刁钻，只要你实际动手写过，基本都能答上来。最忌讳的是代码不是自己敲的，一问实现细节就支支吾吾。哪怕只看懂一半，也要亲手把核心流程走一遍，把关键代码的注释写明白。

6.3 进阶功能：低成本高回报的扩展方向

如果做完核心功能后还有富余时间，我推荐你加两个低成本高回报的扩展：一是Redis缓存热点攻略数据，缓存穿透和缓存过期策略能成为答辩的加分话题；二是简单的管理员后台，至少包含用户管理和内容审核功能，这会让系统的完整性提升一个档次。这两个功能不至于让你陷入过度开发，但会让你的项目在同类题目中明显“多一层东西”。

我个人实际带完这类项目最深的感受是：旅游社交分享系统真正的价值不在于它多先进，而在于它逼着你把“用户→内容→互动→关系”这条完整链路走通。只要完整开发一遍，Spring Boot、MyBatis-Plus、MySQL、JWT、Vue前后端交互这些技能点就像肌肉记忆一样长在身上了，后面投简历做笔试题，遇到类似场景心里完全不慌。选题的聪明和答辩的漂亮，都藏在这份“真的做完”的底气里。祝你的毕设一路绿灯，去看到自己想看到的风景。