每年到这个时间点，总有一批计算机专业的同学为毕业设计选题愁到头秃。图书馆坐了一下午，知网翻了几十页，系统需求分析写了两行就删掉。如果你正在经历这个阶段，看到“农村综合风貌展示平台系统”这种题目，第一反应多半是：这能做出什么花样？

我先说个结论：这题不仅不难，而且是个性价比非常高的选择。为什么？因为农村风貌展示类系统属于典型的信息展示与内容管理型应用，业务逻辑清晰、需求边界明确、技术栈主流，同时又有足够的空间做出展示效果和功能亮点。更关键的是，它和国家目前大力推动的数字乡村、乡村振兴方向高度契合，在论文的选题背景和意义部分天然带有价值加持。你不需要做出一个AI识别农作物病虫害的系统，也能拿到一个体面的分数。

这篇文章就是围绕这个项目，把从选题思路、技术选型、功能设计、数据库建模，到论文结构、答辩要点、源码部署的完整链路，全部过一遍。整篇内容不是我拍脑袋编的，而是基于大量真实毕设项目的实操经验整理出来的。适合正在做Java + Spring Boot方向毕设的同学，也适合想拿一套现成源码但看不懂架构的读者。

我先把这个项目的整体定位讲清楚，再一项项拆。

1. 这个项目到底做了哪些事：平台定位与核心功能拆解

很多同学拿到“农村综合风貌展示平台系统”这个题目，第一反应是做一个网页版PPT——轮播图、静态文字、几张照片就完事了。这种思路大错特错。如果只是静态页面，那叫网页设计课的大作业，不叫毕业设计。毕设的系统，必须有一个明确的业务闭环：有人录入数据，有人审核数据，有人消费数据。也就是说，它必须同时具备内容生产端和内容消费端，再加上一层管理端做权限控制。

我们把这个系统拆成三个端口来看：

面向游客/访客的前台展示端。这是平台的脸面，承担着“风貌展示”的核心使命。包含乡村概况展示（历史沿革、地理位置、人口面积）、特色风光展示（自然景观、古建筑、田园风光）、民俗文化展示（节庆活动、非遗项目、地方戏曲）、农特产品展示（产品图鉴、产地故事、购买渠道）。内容形式不能是干巴巴的文字和静态图，至少要有图片画廊、视频嵌入、地图标注这几个维度。

面向村级管理员/普通工作人员的内容管理端。每个村或每个管理员有一个账号，负责自己管辖范围内的内容上传与维护。景点图片的上传、民俗活动文字资料的编写、农产品信息的更新，都是在这个端完成。内容提交后并不是直接发布上线，而是先进待审核状态。

面向系统管理员的后台审核端。平台管理员对提交上来的内容做审核，决定“通过并发布”“驳回修改”或“删除下线”。除此之外，管理员还可以维护用户角色、分配权限、查看平台的访问统计、管理轮播推荐位。

从技术层面看，这个系统至少包含以下核心模块：用户认证与授权模块、乡村信息管理模块、图片/视频资源管理模块、内容审核工作流模块、前台检索与分类浏览模块、数据统计与可视化模块。

听到这里你就明白了，这已经不是一个简单的展示站，而是一个带完整内容生命周期管理的CMS系统。这种设计在论文里非常好写——业务需求分析、功能模块划分、数据库关系设计、核心流程时序图，每一块都有实实在在的内容可以写，不愁凑字数，每句话都在说正事。

2. 技术选型逻辑：为什么是Java + Spring Boot，架构上都包括什么

题目已经写明了基于Java + Spring Boot架构，这就要求你的系统必须是标准的B/S架构，采用前后端分离或半分离的开发模式。下面我把这套技术栈的每个选型理由讲清楚，答辩的时候老师问到你为什么选这个框架，你直接照这套逻辑答就行。

2.1 后端核心框架：Spring Boot的价值不只是“简化配置”

Spring Boot在当前Java Web开发领域已经属于事实标准。很多同学写论文的时候喜欢提“Spring Boot简化了Spring的XML配置”，这句话没有错，但太浅了，答辩老师听这种回答听了十年，耳朵都起茧了。你要说的是：基于“约定优于配置”的设计思想，Spring Boot通过自动配置机制和起步依赖，让开发者只需要关注业务代码本身，而不用关心大量基础设施的装配过程。

实际开发中，你真正用到Spring Boot的核心能力是这几个：

一是自动配置（Auto-Configuration）。引入spring-boot-starter-web依赖后，内嵌的Tomcat服务器自动启动，Spring MVC的DispatcherServlet自动注册，你只需要写一个@RestController和若干@Service就能把接口跑起来。

二是Starter依赖管理体系。引入spring-boot-starter-data-jpa或mybatis-spring-boot-starter，数据库访问层所需的DataSource、SqlSessionFactory、TransactionManager全部自动装配。

三是Actuator与监控体系。引入spring-boot-starter-actuator后，系统对外暴露健康检查端点、性能指标端点。论文里可以在系统非功能需求分析中提一句“系统支持运行状态实时监控”，这是一个加分项。

2.2 持久层框架：JPA还是MyBatis

持久层框架的选择，是Java毕设里一个绕不开的问题。这里给出两个主流方案的对比：

农村风貌展示平台本质上是一个内容管理类系统，列表查询、分页查询、按分类/关键字筛选是核心数据操作，表结构之间有一些外键关联但不会绕很多圈。我个人更推荐使用Spring Data JPA，因为它的Repository接口设计非常适合做“按条件查询”这类操作，而且实体关系映射（多对一、一对多）的写法写在论文里非常清晰。但如果你对SQL更熟、心里更踏实，选MyBatis-Plus也完全没问题，RowBounds或者PageHelper做分页都很成熟。

有一点要注意：不管你选哪个持久层框架，你不能只写CRUD。论文的“系统实现”章节里至少要有一个联表查询的场景描述和代码展示。比如“按区域分类查询乡村列表，同时统计每个乡村下面的景点数量并关联展示第一张封面图”，这就是一个典型的多表关联聚合查询场景，能在答辩时体现你的数据建模能力。

2.3 前端技术方案：模板引擎渲染还是Vue前后端分离

这是另一个高频答辩问题。两种方案我都做过，实话实说：如果你的前端基础一般，用Thymeleaf服务端渲染模板能省非常多的事，你的控制器返回视图名称，模板引擎填充数据生成HTML页面，整站就是一个Spring Boot工程，部署时打成JAR包直接跑。但“省事”的反面是，论文里的前端交互描述会相对单薄，页面动态效果也有限。

如果你有一定的Vue基础，强烈建议做前后端分离。后端只暴露JSON接口，前端用Vue + Element UI构建单页应用。开发环境下前端跑在8080端口，后端跑在9090端口，通过代理转发解决跨域问题。正式部署的时候，把Vue项目打包后的dist目录拷进Spring Boot的src/main/resources/static下面，后端把静态资源和接口一起服务，这样最终产品形态还是一个独立部署的JAR包。这个“Vue打包放进Spring Boot”的部署方案在答辩时非常加分，因为它体现了你对前后端工程化部署的理解。

我这里给一个Vue打包进Spring Boot的标准流程，后面部署章节还会再细讲：

# 前端工程目录下执行 npm install npm run build # 打包完成后，dist目录包含 index.html + static 资源目录 # 将dist下面的内容全部复制到后端的 src/main/resources/static 目录 # 后端工程目录下执行 mvn clean package java -jar target/village-showcase-0.0.1-SNAPSHOT.jar

2.4 数据库选择与架构分层

数据库不用纠结，MySQL就行，版本5.7或8.0都可。存储引擎用InnoDB，字符集统一为utf8mb4——对于农村风貌展示这个场景，民俗文化内容里出现生僻字和特殊符号的概率很大，utf8mb4能完整支持。

架构分层上，标准的三层架构：

• Controller层（表现层）：接收HTTP请求，参数校验，调用Service层，返回统一响应体。
• Service层（业务层）：业务逻辑编排，事务控制，调用DAO层接口。
• Repository/DAO层（数据访问层）：继承JpaRepository或编写Mapper接口，执行SQL与ORM映射。

再往下还有一个Model/Entity层，对应数据库表结构。DTO（数据传输对象）和VO（视图对象）在层间穿梭传递。

这种分层在论文里能画出非常标准的系统架构图，层与层之间的调用关系一目了然。答辩时老师一般会问“Controller直接操作Repository行不行”，你要回答“不行，Controller必须经过Service层，因为业务规则和事务边界必须控制在Service层，Controller只负责协议解析和响应封装”。这句话一出来，老师就知道你理解分层架构的本质了。

3. 数据库建模实战：农村风貌展示平台的数据表设计

数据库设计是一个毕设的骨架，也是论文中的重头戏。农村风貌展示平台我建议设计不少于8张核心表，下面我把核心表结构和设计意图拆开讲。

3.1 核心表清单与关系说明

这8张表之间靠外键或逻辑关联字段形成网状关系。village表是一村一行的主数据，scenery、culture、produce都通过village_id关联到具体的乡村。每一条内容在发布前都会在content_audit表里生成一条审核记录。

3.2 值得注意的几个设计细节

图片列表字段怎么存：景点照片往往不止一张。常见的做法有两种，一种是单独建一张图片表（id, content_type, content_id, image_url, sort_order），另一种是直接在景点表里用一个JSON字符串存图片URL数组。JPA配合MySQL的@Convert注解可以将List字段序列化为JSON存进一个字段，读取时再反序列化。第一种更规范但表多，第二种更简单。做毕设我建议第一种，因为图片子表的增删改查能在论文中单独写一小节，体现你对一对多关系的处理能力。

用户权限模型设计：用户、角色、用户角色关联三张表是经典RBAC权限模型。这里的角色不需要做得很细，“超级管理员、平台运营、村级管理员”三种角色即可。村级管理员只能管理自己所在乡村的内容，这种数据权限的过滤不能靠SQL硬编码，应该在Service层先根据用户角色查询其可管理乡村ID列表，再带进查询条件中。

内容审核状态流转：status字段用int类型，0待审核、1审核通过、2已驳回、3已下线。驳回时必须填写审核意见，这个意见要存到content_audit表的audit_comment字段里，前台提交人才能在“我的提交”里看到驳回原因。这种状态机的设计是内容管理系统的灵魂，写论文时你甚至可以画一张状态流转图。

时间字段统一处理：每张表都包含create_time、update_time两个字段，插入和更新时自动填充。JPA里用@PrePersist和@PreUpdate回调方法，或者用Hibernate的@CreationTimestamp、@UpdateTimestamp注解。这个细节虽然小，但课堂上学的时间处理能落到实处的并不多，做会了是一个亮点。

3.3 一个典型的组合查询SQL设计

前台首页要展示“每个乡村的概览卡片”，卡片上包含：村名、区域、封面图、景点数量、简介。这个查询涉及village表、scenery表、图片表的关联聚合。用JPA的@Query可以写：

@Query(value = "SELECT v.id, v.name, v.region, v.cover_image, v.introduction, " + "(SELECT COUNT(s.id) FROM scenery s WHERE s.village_id = v.id) AS scenery_count " + "FROM village v ORDER BY v.sort_order ASC") List<VillageCardDTO> findVillageCards(Pageable pageable);

这种写法在Controller层返回给前端后，每张卡片就是一个VillageCardDTO对象。DTO里包含了前台展示所需要的所有字段，不用额外循环查数据库。

提示：查询大列表时不要图省事把实体直接返回给前端，既暴露了内部字段，又无法控制需要的数据结构。定义专门的DTO/VO类返回，是工程化开发的基本素养。

4. 从零搭建：核心功能模块实现的关键链路

这一部分我按照真实的开发流程，从工程初始化到核心功能编码，把关键步骤和容易踩坑的地方过一遍。

4.1 工程初始化与基础配置

用 Spring Initializr 生成基础工程，依赖选择Spring Web、Spring Data JPA、MySQL Driver、Validation、Lombok。Java版本推荐1.8或11，Spring Boot版本用2.7.x即可——很多同学一上来就选3.x，但3.x要求JDK17，如果你的本机环境还是JDK8，版本会直接跑不起来。这里给个建议：毕设不要追求“最新版本”，追求“最稳组合”。之前有个学生选了Spring Boot 3.2，JDK21，MyBatis-Plus还没适配，卡了两天才发现是版本兼容性问题。折腾版本的时间给你论文，不香吗？

生成完成后，修改application.yml：

server: port: 9090 spring: datasource: url: jdbc:mysql://localhost:3306/village_showcase?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: your_username password: your_password driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: update show-sql: true properties: hibernate: format_sql: true # 自定义文件上传路径，放在项目根目录下 file: upload-path: ./upload/

两点值得说明一下。ddl-auto: update在开发阶段非常方便，实体类改了后自动同步表结构，但正式演示部署时建议改为validate或none，避免意外修改表结构。show-sql: true开发时打开能看到JPA实际执行的SQL，对排查性能问题和联表查询的正确性帮助极大。

4.2 统一响应体与全局异常处理

前后端分离的项目里，后端接口要有一个统一的JSON响应结构。我习惯用以下格式：

{ "code": 200, "message": "success", "data": { } }

code为200表示成功，非200表示失败。前端拿到响应后先判断code，再决定渲染数据还是弹出错误提示。这个响应体用泛型类定义：

@Data public class ApiResponse<T> { private Integer code; private String message; private T data; public static <T> ApiResponse<T> success(T data) { ApiResponse<T> response = new ApiResponse<>(); response.setCode(200); response.setMessage("success"); response.setData(data); return response; } public static <T> ApiResponse<T> error(Integer code, String message) { ApiResponse<T> response = new ApiResponse<>(); response.setCode(code); response.setMessage(message); return response; } }

全局异常处理用@RestControllerAdvice，统一拦截业务异常、参数校验异常和兜底Exception。这样Controller层代码干净利落，每个接口只需要关注正常流程，异常全部丢给全局处理器。

4.3 用户认证与权限控制

用户认证毕设建议用JWT（JSON Web Token）而不是Session，理由有两点：一是前后端分离架构下JWT天然适合无状态认证，token放在请求头里，后端不用维护会话状态；二是JWT的签名验证逻辑写在论文里非常好展示。

实现链路是：

1. 用户输入用户名密码请求/api/auth/login。
2. 后端校验用户名是否存在、密码是否匹配（BCrypt加密存储）。
3. 校验通过后生成JWT令牌，令牌中携带用户ID、用户名、角色编码。
4. 后续请求在Header中携带Authorization: Bearer <token>。
5. 拦截器（HandlerInterceptor）解析token，把用户信息放入ThreadLocal供后续业务使用。

权限控制上，后端接口在Controller方法上加自定义注解或直接用Spring Security的@PreAuthorize，按角色的接口访问控制。如果不想引入Spring Security这个偏重的组件，可以自己写一个简单的拦截器做“是否登录”的判断，再在Service层做“是否有权限操作该数据”的判断。对毕设来说这已经足够，而且这部分自研逻辑写在论文里更有说服力。

4.4 内容上传与图片处理

乡村风光展示离不开图片和视频，文件上传模块是必修课。视频文件往往几十上百MB，上传时要限制大小和类型。图片建议做压缩处理——很多同学直接用手机原图上传，一张图5MB，前台打开页面卡成幻灯片。后端在接收到图片后利用Thumbnailator库生成缩略图，保存到磁盘的同时把缩略图URL存入数据库。

InputStream inputStream = multipartFile.getInputStream(); File thumbnailFile = new File(uploadDir + "/thumb_" + fileName); Thumbnails.of(inputStream) .size(400, 300) .outputQuality(0.8) .toFile(thumbnailFile);

缩略图用于列表页展示，原图用于详情页点击查看。这个设计在答辩时是一张好牌——它体现了你考虑了真实生产环境下的性能问题，而不只是把功能跑通。

4.5 前台检索与数据组装

前台页面需要一个“乡村风貌”列表页和一个“民俗文化”列表页，都支持按照区域或类型筛选。Spring Data JPA中可以用Specification实现动态查询，也可以写@Query根据可选参数拼SQL。我的习惯是直接用@Query，条件少、直观：

@Query("SELECT v FROM Village v WHERE " + "(:region IS NULL OR v.region = :region) AND " + "(:keyword IS NULL OR v.name LIKE %:keyword% OR v.introduction LIKE %:keyword%)") Page<Village> searchVillages(@Param("region") String region, @Param("keyword") String keyword, Pageable pageable);

搜索关键字时用LIKE %keyword%即可，不用上全文索引。如果后续加了“资讯动态”模块，再考虑引入Elasticsearch做全文检索——但毕设不建议这么干，因为这会让整个系统的复杂度上一个台阶。

4.6 权限拦截与数据权限过滤

村级管理员只能维护自己村的资料，这个逻辑在Service层实现：

public Page<Scenery> listScenery(Long currentVillageId, Pageable pageable) { if (!isPlatformAdmin()) { // 非平台管理员，强制限定其管理乡村范围 currentVillageId = getLoginUser().getVillageId(); } return sceneryRepository.findByVillageId(currentVillageId, pageable); }

这种基于登录用户Context的数据过滤，是一个很容易被忽略但体现工程经验的地方。单纯在界面上隐藏按钮不算权限控制，因为接口可以被直接调用。真正的权限控制必须落在后端代码逻辑里。

5. 内容运营视角：让平台不是“演示完就废”的摆设

说实话，很多毕设项目做到能跑、能演示、能截图放进论文，就算完工了。但如果你想让这个项目在答辩时更耐打，甚至之后能放进简历里，我建议往“可持续运营”的方向再推一把。农村综合风貌展示平台最容易陷入的窘境是：上线时录了几条测试数据，之后再也没有内容更新，整个平台死气沉沉。

要避免这个窘境，在设计阶段就要考虑内容从哪里来。两种思路：

一是做数据采集工具。你在开发准备阶段，可以针对性地去各县区官方文旅平台、乡镇政府信息公开网站，爬取一些公开的非涉密数据样本作为系统初始数据，比如村庄简介、人口面积、特色产业介绍。这个工作不需要写爬虫，手动整理进Excel再通过一个数据初始化脚本导入即可。重点是确保初始数据有足够规模——每个乡村条目配齐封面图、简介、至少3个景点和1个民俗项目。论文里的“系统测试”章节需要这样的数据基础来支撑功能和性能测试。

二是设计“内容众包”机制。在系统里增加一个“游客投稿”功能：游客在浏览乡村详情页时可以上传自己拍的照片，附一句“拍摄于XX村”。照片进入待审核池，由村级管理员确认后展示在乡村风光图廊中。这个功能在技术难度上并不高，但在业务价值上非常亮眼——全民参与乡村宣传，特别是农产品和旅游资源的传播，是真实场景中最需要的功能形式。答辩时老师问“你这个平台怎么保持内容活力”，这个功能就是你的答案。

从用户体验角度，前台页面还可以增加两个贴心的小功能：

• 乡村位置地图标注：接入高德或百度地图的JavaScript API，每个乡村页面上嵌入地图组件，标记出景点位置。游客看完了介绍，往下翻就能看到地理位置，一键发起导航。这个功能接入成本极低（注册账号申请一个开发者Key），视觉冲击力却很强。
• 农产品在线询盘：农产品展示页提供一个“联系农户”的按钮，点击后弹出卡片展示联系人电话和微信，或者跳转到一个简易的询价留言表单。不用做支付、购物车这些重型模块，避免把毕业设计的复杂度推到交易系统的范畴。

这两条加上游客投稿，共同回答了“这个平台除了展示还有什么用”的问题。一个只有展示功能的网站是没有生命力的，能把“看的人”转化成“参与的人”“联系的人”，这个平台才算是真正立住了。

6. 论文框架与答辩准备：让你的代码工作量“被看见”

很多同学技术功能做了不少，但论文写得像流水账，答辩PPT一页页翻过去全是截图，老师看完面无表情。问题的核心在于：你没有把“为什么这样做”的思考过程写出来，而答辩老师恰恰最看重的就是这个。我基于这篇项目的完整论文结构，把每一章该写什么重点罗列一遍。

6.1 论文整体框架建议

第一章 绪论：核心是研究背景与意义。不要只写“乡村振兴是国家战略”，要具体到这个平台能解决什么问题——乡村数字资源分散、对外展示渠道缺乏统一入口、旅游与农产品资源信息不对称。然后写国内外研究现状，把乡村旅游信息化平台、数字乡村建设相关文献梳理一遍，重点在“现有系统的不足”上，以此引出本系统。

第二章 相关技术介绍：Java语言、Spring Boot框架、Spring Data JPA、MySQL、Vue/Thymeleaf、JWT、前端组件库。每一节的技术介绍除了讲是什么，还要讲为什么选它——这正好呼应我前面写的选型逻辑。

第三章 系统分析与需求建模：可行性分析（技术、经济、操作三方面）、用户角色分析（游客、村级管理员、平台管理员）、功能需求分析（用用例图配合用例描述表）、非功能需求分析（性能指标、安全要求、可用性）。这一章是拉分项，写得好会让老师觉得你的需求分析功底扎实。

第四章 系统设计：总体架构图（层次结构）、功能模块划分（用功能结构图）、数据库设计（ER图、核心表结构说明）、接口设计（核心RESTful接口的URL与参数定义）、关键业务流程设计（内容发布审核流程、用户认证流程）。

第五章 系统实现：按功能模块逐项说明实现方式，每个模块配“核心代码片段 + 运行界面截图 + 关键实现说明”三件套。代码片段选有代表性的，不要全贴。

第六章 系统测试：测试环境说明、功能测试用例表（用例编号、测试步骤、预期结果、实际结果）、性能测试（JMeter并发访问首页接口，给出响应时间数据）、测试结论。

第七章 总结与展望：总结系统完成的内容与不足，展望部分写后续可以扩展的方向——如接入电商功能、建设VR全景体验等。

6.2 答辩中常见的高频问题与应对思路

技术架构类：

• “Spring Boot和传统的Spring MVC有什么区别，你项目里Spring Boot起了什么作用？”——从自动配置、起步依赖、内嵌容器三个角度回答，参考第2节内容。
• “你的数据库为什么这么设计？表之间的关联关系是什么？”——直接把你自己的ER图和表结构讲一遍，重点讲内容审核表如何与各内容表关联。
• “数据权限是怎么控制的？用户能不能越权修改？”——回答Service层做了数据范围过滤，并指出接口层不能作为唯一控制手段。

功能逻辑类：

• “内容提交后，整个流程是怎么流转的？”——按“村级管理员提交 → 平台管理员审核 → 前台可见/驳回修改”的流程，配合状态字段变化来说。
• “游客能不能上传照片？上传的内容安全怎么保证？”——先审核后发布，图片后缀名白名单校验，文件大小限制，敏感内容人工审核。

展示效果类：

• “你这个平台和普通的微信公众号乡村宣传页有什么区别？”——微信推文是一次性传播，系统是持续可更新的平台，并且有完整的内容管理、审核、分类检索能力。

提示：答辩时不要背稿，把你做过的真实细节讲出来。比如“我当时踩过一个坑，因为MySQL的时区没设成Asia/Shanghai，数据库存的时间总是比实际早8小时”“图片上传没做大小限制，结果页面加载很慢，后来加了一层缩略图”。这种真实的细节比任何华丽的理论都更有说服力。

7. 拿到源码后从零跑通的实操指南

最后这部分是实操向的。如果你手里已经有一套这类项目的源码+论文，打算先跑通再做二次改造，下面这份指南能帮你少走弯路。源码跑不通的原因，九成是环境问题，一成是配置问题，很少是代码本身的问题。

7.1 环境准备清单

这里特别提醒：安装JDK后一定要配置JAVA_HOME环境变量，很多同学卡在mvn -v命令能执行但IDEA里编译失败，就是环境变量没配对。把JAVA_HOME配置到JDK安装根目录，再把%JAVA_HOME%\bin加进PATH，完之后重新打开命令行窗口验证。

7.2 数据库初始化的两个关键步骤

源码通常自带village_showcase.sql数据库脚本文件。执行流程是：

CREATE DATABASE village_showcase DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE village_showcase; SOURCE /你本地路径/village_showcase.sql;

如果脚本文件里有中文注释或中文数据，导入时提示乱码，用下面这个命令行参数强制指定编码：

mysql -u root -p --default-character-set=utf8mb4 < village_showcase.sql

导入完成后查一下核心表的数据量，比如SELECT COUNT(*) FROM village;，确认有数据再进下一步。

7.3 配置文件修改的三个必改项

跑起来之前，application.yml里有三个地方必须改成你自己的环境：

一是数据库连接信息，URL里的数据库名、host、端口，以及username和password。二是文件上传路径，file.upload-path改成你本地的绝对路径，比如D:/project/upload/，否则上传文件会写入到不可预知的相对目录。三是JWT密钥，源码里通常有一行jwt.secret（也可能是jwt.token-secret），这个是一串base64或普通字符串，出于安全考虑建议改成你自己的随机字符串，长度不要少于32位。如果源码里没有JWT配置，找一下自定义配置类@ConfigurationProperties(prefix = "jwt")对应的属性。

7.4 从IDEA启动到验证通的完整操作步骤

1. 用IDEA以Maven工程方式打开源码根目录，等待右侧Maven面板依赖下载完成。如果下载很慢或卡住，在settings.xml里配置阿里云镜像仓库，这个步骤值得提前做。
2. 确认SDK版本正确：File → Project Structure → Project Settings → Project → SDK，选择你安装的JDK版本。
3. 启动MySQL服务，确认命令行能mysql -u root -p正常进入。
4. 运行启动类中带@SpringBootApplication注解的main方法，观察控制台日志。
5. 等到日志出现Started Application in x.xxx seconds，浏览器访问http://localhost:9090（端口以配置文件为准）。
6. 验证三个端：前台首页能打开、登录接口能返回token、登录后能进入管理后台。如果前两步通过说明主链路通了。

7.5 高频报错排查速查表

这里我要单独讲一下静态资源映射这个坑。Spring Boot默认只映射classpath:/static/目录下的资源。如果把上传文件放在项目运行目录之外的./upload/，访问http://localhost:9090/upload/xxx.jpg会直接404。原因是这个路径不在默认资源映射范围内。你需要在配置类里手动加上虚拟路径映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${file.upload-path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath); } }

这个坑几乎每个做文件上传项目的同学都会踩一遍，提前看到就是提前避雷。

7.6 部署上线：一台云服务器搞定公开访问

毕设演示阶段，最多需要一台最小配置的云服务器。系统量大头是JAR包、MySQL、前端静态资源这三样，而这三样全部在一个JAR包内置了，部署成本极低。流程：

1. 在服务器上安装JDK、MySQL，创建数据库并导入初始数据。
2. 本地执行mvn clean package，在target目录得到JAR包。
3. 用scp或宝塔面板将JAR包上传到服务器。
4. 执行nohup java -jar village-showcase-0.0.1-SNAPSHOT.jar > app.log 2>&1 &后台启动。
5. 配置安全组规则，开放9090端口。
6. 浏览器访问http://服务器IP:9090，完成在线访问验证。

如果配置了域名，再加一道Nginx反向代理，将80端口的请求转发到9090端口。这个部署闭环做完之后，你在论文“系统测试”和“总结与展望”章节里就有了真实运营环境和线上验证数据，而不是在本地自说自话。

8. 拓展与加分方向：如何让这个项目从“中规中矩”变成“眼前一亮”

每个学校的评分标准不同，但有一条是共识：做别人没想到的、但又在合理工程范围内的功能，是拉开分差的关键。下面这几个拓展方向，成本可控，性价比高。

方向一：数据可视化大屏。在农村风貌展示平台的管理端加入一个数据看板页面，用ECharts展示平台的访问量趋势、内容分类占比、各乡村内容数量排名、待审核工单数量。数据直接从数据库聚合查询后由后端返回JSON，前端用ECharts渲染。这个功能写起来不难，但在答辩现场投到大屏幕上，效果是碾压性的一页PPT截图能比的。

方向二：乡村VR全景展示。利用全景图片（720度全景）嵌入前端页面，游客在景点详情页可以拖拽浏览全景视角。全景图片采集可以用手机全景模式拍摄，图片托管到七牛云或阿里云OSS，前端用原生pannellum库加载。注意这一块不需要自建全景服务，接入第三方托管是最稳的。

方向三：基于Redis的热度统计。引入Redis，统计每个乡村页面的浏览热度，在前台首页做成“热门乡村TOP5”榜单。实现链路是前端每次请求详情接口时POST一个浏览事件，后端异步递增Redis中的计数器，后台定时任务每隔一段时间将计数器写回MySQL。这个设计把“实时统计”和“持久化”的权衡讲清楚了，是一个非常好的非功能需求体现。

方向四：微信小程序端。如果你的前端基础较强，可以把前台展示端做成一套微信小程序。后端接口完全复用Spring Boot提供的RESTful API，小程序端用微信开发者工具独立开发。论文里就多了一章“基于微信小程序的移动端设计”，工作量翻倍但评分上限也翻倍。

这几个方向不建议全做，挑一个做透就足够。贪多嚼不烂是毕业设计最大的坑，做太多功能导致每个功能都半成品，在答辩时反而成为被攻击的靶子。我见过最可惜的例子是有人做了大数据大屏+推荐算法+微信小程序三个方向，结果每一个都被老师追问出了破绽，最后只能羞赧地说“这里我只是做了一个demo”。还不如踏踏实实把一个方向做到能现场演示流畅、代码完整、逻辑严谨。

最后，从一个走过这段路的人的角度说几句。毕设是一个把几年学的知识整合落地为具体系统的过程，它的价值不在于评级证书上多高的一档，而在于你真正把一个模糊的方向逐步变成一个有结构、有实现、有说服力的完整作品。农村综合风貌展示平台这个命题，看起来朴素，但只要你把架构分层做清楚、功能闭环做完整、论文逻辑写有层次，它的上限并不低。

如果这篇文章正好是你准备这个项目的起点，我的建议是从数据库建模开始动手，把前面第3节的8张表建好，再一格格填代码。地基稳了，上面盖什么都稳；表结构对了，后面每写一行代码心里都有底。