戈玄白今天要做题最近帮一个学弟把他的毕设项目从头到尾捋了一遍，题目是“基于 Spring Boot 的网络云端日记本系统设计与实现”。说实话，这类题目在Java Web方向的毕设里属于经典中的经典，用户认证、日记的增删改查、标签分类、全文检索、数据导出，再加一个云端部署，基本把大学四年学的东西都串起来了。但越是这种“看起来很常规”的项目，越容易在细节上翻车：版本不兼容、部署内存不足、远程调试连不上、前后端联调时分不清到底是谁的Bug。
这篇文章会把这套云端日记本系统从需求拆解、技术选型、数据库设计、核心代码实现，到部署上线和常见问题排查，完完整整拆开讲一遍。你在做类似选题的话，可以直接照着这套思路去落地，很多坑我已经替你踩过了。
1. 需求拆解与整体方案选型
1.1 这个系统到底在解决什么问题
日记本这个产品形态，本质上是一个“以时间为轴的个人内容管理工具”。传统的本地日记本，比如手机备忘录、Windows记事本，最大的痛点就是数据不跨端、不备份、容易丢。云端日记本的核心价值，就是把日记数据从本地搬到服务器上，做到多端访问、集中存储、随时备份。
从毕设的角度来看，这个题目还多了一层教学意义：它可以完整覆盖一个Web系统从0到1的全部环节。用户注册登录涉及的拦截器和Token鉴权是核心考点，日记的CRUD操作是Java Web的基础功，标签分类考察的是多对多表关系的设计，全文检索能体现你对数据库索引和搜索方案的理解，部署上线则直接检验你对自己写的代码到底熟不熟。
学弟一开始问我，这个项目是不是太简单了，怕答辩时没有亮点。我的看法是：题目简单不代表你可以做得简单。同样的需求，不同深度的人做出来完全是两个东西。比如“用户登录”，你可以只做一个用户名密码比对，也可以做成JWT无状态鉴权；比如“搜索日记”，你可以用LIKE '%关键词%'糊弄过去，也可以引入倒排索引的思路用全文索引优化。这些深度上的差异，恰恰是答辩时能展示个人能力的地方。
1.2 为什么选 Spring Boot 而不是其他方案
这个项目技术栈选型其实没什么悬念，Spring Boot 是当前Java后端开发的事实标准，也是绝大多数高校Java Web课程的方向。但选它不是因为“大家都在用”，而是它确实契合这种单体应用的开发节奏。
Spring Boot 最核心的价值是“自动配置”。传统的SSH（Spring + Struts + Hibernate）或者SSM（Spring + SpringMVC + MyBatis）框架，光是配置XML文件就能耗掉你两三天时间，各种扫描路径、事务管理器、视图解析器，稍微写错一个标签项目就起不来。Spring Boot 通过 starter 机制把这些繁琐配置都封装掉了，你只需要引入一个 spring-boot-starter-web 依赖，写一个 @SpringBootApplication 注解的启动类，一个可运行的Web项目就搭好了。
但它不是没有代价。自动配置带来的问题是“黑盒化”，你很难知道底层到底装配了什么。比如引入 spring-boot-starter-data-redis 之后，Spring Boot 会默认帮你创建一个 RedisTemplate Bean，你以为直接注入就能用，结果序列化器默认是 JdkSerializationRedisSerializer，存进去的Key带了一堆前缀，存中文直接变成乱码。这种问题在答辩时特别容易被问到，所以我的建议是：用 Spring Boot 开发没问题，但底层原理必须搞明白，至少要弄清楚自动配置的触发条件和关键配置项的覆盖方式。
1.3 前后端分离还是服务端渲染
这是一个很多同学纠结的问题。我的建议非常明确：选前后端分离，但前端不要自己造轮子。
前后端分离的意义在于，它把你的项目分成了两个可以独立开发、独立部署的部分，后端只提供JSON接口，前端只管页面渲染和交互。这种方式不仅是当前企业开发的主流模式，更重要的是它天然适合远程调试——你可以在本地把后端跑起来，用Postman先调试接口，前端那边只管对接，不用两个人挤在一台机器上改代码。
前端技术栈我建议用 Vue 3 + Element Plus，原因很简单：组件库成熟，文档全，社区活跃，遇到问题搜一下基本都有答案。而且 Vue 的学习曲线比 React 平缓很多，对于一个毕设来说足够用了。
但有一点要提醒你：如果你对前端不太熟，千万不要自己从零写一堆复杂交互。比如富文本编辑器，别用那种需要你自己封装一堆API的库，直接选一个开箱即用的，比如 wangEditor 或者 TinyMCE 的 Vue 版本，能省大量时间。日记的编辑体验虽然不是核心考点，但它直接决定了演示效果——你总不想答辩的时候在编辑器里打几个字都卡半天。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心功能梳理与环境搭建
2.1 功能模块的划分
这个系统的功能模块，我在设计时是这样拆分的：
- 用户模块：注册、登录、注销、密码加密存储、登录状态校验
- 日记模块：新增日记、编辑日记、删除日记（逻辑删除）、日记列表分页查询、日记详情查看
- 标签模块：标签的创建、删除、编辑，日记与标签的多对多关联，按标签筛选日记
- 搜索模块：关键词搜索日记标题和正文内容
- 统计模块：日记总数、本月新增日记数、按月份统计的日记数量趋势
- 数据导出：将用户的日记导出为Markdown或TXT文件
这样拆分的好处是，每个模块都能对应到具体的数据库表和接口，后续写文档和画功能结构图都特别清晰。答辩的时候老师让你“介绍一下你的系统有哪些功能”，你按这个顺序讲，逻辑上就不会乱。
2.2 开发环境与版本选择的教训
环境这块我要多说两句，因为这是最容易出问题的地方，尤其是版本兼容性。
我的建议组合是这样的：JDK 8（对应热词里说的 jdk1.8，稳定且兼容性最好）+ Spring Boot 2.7.x + MySQL 5.7 + Maven 3.6.3。这套组合是经过大量项目验证的“安全牌”。
为什么不用 Spring Boot 3.x？这个问题我专门跟学弟强调过。Spring Boot 3.0 从2022年底发布，确实带来了很多新特性，比如 GraalVM 原生镜像支持、Jakarta EE 9 命名空间迁移，但它的底层最低要求是 JDK 17。如果你电脑上装的是 JDK 8，直接引入 Spring Boot 3.x 的依赖，项目根本起不来，报错信息是 UnsupportedClassVersionError。
另外，Spring Boot 2.7 是 2.x 系列的最后一个版本，官方维护时间最长，社区资料最多，网上搜到的问题解决方案基本都是针对这个版本的。你找一个冷门的 2.4 或者 2.5，遇到问题可能连报错信息都搜不到几条。
MySQL 也建议用 5.7，不要急着上 8.0。8.0 的默认认证插件是 caching_sha2_password，很多老版本的数据库连接驱动不兼容，会报 Authentication plugin 'caching_sha2_password' cannot be loaded 这个错。虽然可以通过改认证插件来解决，但对毕设来说没必要给自己找这个麻烦。
2.3 Maven 依赖管理的坑
Maven 是Java项目最常用的构建工具，它的核心是 pom.xml 文件里的依赖管理。但在实际使用中，你大概率会遇到依赖冲突和下载失败的问题。
依赖冲突最典型的场景是这样的：你引入了 A 依赖，A 内部传递依赖了 B 的 1.0 版本，你又在项目里显式声明了 B 的 2.0 版本，最后项目运行时会同时加载两个版本的 B，导致方法签名对不上，运行期直接 NoSuchMethodError。这种问题排查起来特别痛苦，因为编译期不报错，一运行就崩。
我的经验是，一定要用好 IDEA 自带的依赖分析工具。打开 pom.xml，右键选择 Diagrams -> Show Dependencies，就能看到完整的依赖树。发现有版本冲突的依赖，在引入时直接用 exclusion 排除掉不想要的传递依赖，或者统一用 dependencyManagement 锁定版本号。
还有一个很常见的问题，就是 Maven 仓库下载依赖特别慢。国内环境建议直接把中央仓库地址换成阿里云镜像，在 Maven 的 settings.xml 里配置好，不然你拉一个 Spring Boot 全家桶能等半个小时。
3. 数据库设计与核心表结构
3.1 从需求到表结构的设计思路
数据库设计是一个项目最开始、也最关键的一步。表结构设计得不好，后面写代码就是给自己挖坑。
我拿到需求后的第一件事，不是急着建表，而是先梳理实体之间的关系。这个系统里有几个核心实体：用户（User）、日记（Diary）、标签（Tag）。它们的关系非常明确：
- 一个用户拥有多篇日记，日记和用户是多对一关系
- 一篇日记可以有多个标签，一个标签可以挂在多篇日记下，日记和标签是多对多关系
用户和日记是主从关系，日记表里加一个 user_id 外键指向用户表的主键就行。日记和标签是多对多，需要一张中间表来维护关联关系，这是无数教材里都讲过的经典设计，但在实际操作中很容易被忽略的一个点是：中间表一定要有独立的联合唯一索引，保证同一篇日记不会重复打同一个标签。
3.2 核心表的字段设计
用户表的核心字段设计：
- id：主键，BIGINT，自增
- username：用户名，VARCHAR(50)，唯一索引
- password：密码，VARCHAR(100)，存的是加密后的密文，不是明文
- nickname：昵称，VARCHAR(50)
- avatar：头像URL，VARCHAR(255)，可空
- created_at / updated_at：创建时间和更新时间
- deleted：逻辑删除标记，TINYINT，默认0
密码字段我单独强调一下，绝对不能存明文。哪怕是毕设项目，也要有这个安全意识。我用的加密方案是 BCrypt，Spring Security 框架里自带的 BCryptPasswordEncoder 可以直接用。它的特点是每次加密同一个密码得到的密文都不同，因为里面混入了随机盐值，大大增加了暴力破解的难度。
日记表的核心字段设计：
- id：主键
- user_id：所属用户ID，加索引
- title：日记标题，VARCHAR(200)
- content：日记正文，TEXT
- mood：心情，VARCHAR(20)，可选字段，比如“开心”“emo”“平静”
- weather：天气，VARCHAR(20)，可选字段
- tag_ids：这个不用存，通过中间表关联
- created_at / updated_at
- deleted：逻辑删除标记
TEXT 类型我最开始用的是 LongText，但后来发现其实没必要。正常写日记一篇几千字撑死了，TEXT 类型最大支持 65KB，完全够用，还能省存储空间。
标签表的字段设计相对简单：
- id：主键
- name：标签名称，VARCHAR(20)，加唯一索引
- user_id：所属用户ID
- created_at
为什么标签也要加 user_id？因为标签是用户私有的，同一个用户不能创建两个同名的标签，但不同用户可以用同样的标签名。如果 name 字段只做全局唯一索引，那A用户创建了“工作”标签，B用户就不能再建“工作”标签了，这显然不合理。所以唯一索引应该是 (user_id, name) 的联合唯一索引。
3.3 逻辑删除还是物理删除
这个问题值得单独拿出来讲，因为它是你在面试和答辩时展示思考深度的好素材。
所谓物理删除，就是 DELETE FROM diary WHERE id = 1，一行代码把数据从数据库里抹掉；逻辑删除则是 UPDATE diary SET deleted = 1 WHERE id = 1，数据还在，只是带了一个删除标记。
我推荐用逻辑删除，原因有三个：第一，日记是用户的私有数据资产，误删之后如果能恢复，对用户体验是极大的提升；第二，逻辑删除可以方便地做数据统计，比如你想统计所有历史日记总数，物理删除会让数据不再完整；第三，这是企业开发的普遍的实践方式，在简历上写“熟悉逻辑删除方案”比“会写DELETE语句”要加分。
逻辑删除的代价是，你写的每一个查询都要记得加条件 WHERE deleted = 0。这个很容易漏，所以我的做法是统一在 MyBatis-Plus 里配置全局的逻辑删除字段，让框架自动在 SQL 后面追加条件，这样就不用每次手写了。
4. 核心模块实现与代码逻辑
4.1 用户登录鉴权：从 Session 到 JWT
用户登录鉴权是整个系统最关键的一个模块，也是答辩时老师最爱追问的地方。
传统的方案是 Session 机制：用户登录成功后，服务器在内存里生成一个 Session ID，把它通过 Cookie 写入浏览器，后续每次请求浏览器带着这个 Cookie，服务器通过 Session ID 找到对应的登录用户信息。
这个方案在单体应用里没问题，但它有一点很不方便：服务器内存里的 Session 是有状态的，如果以后部署多台服务器做负载均衡，用户发起的请求被分发到另一台没有这个 Session 的服务器上，就会登录失效。这就叫“有状态服务”的痛点。
所以我选择用 JWT（JSON Web Token）做无状态鉴权。登录成功后，后端生成一个加密的 Token 字符串返回给前端，前端每次请求时在请求头里带上 Authorization: Bearer
JWT 的核心实现思路是：用户登录时，根据用户ID生成一个 Token，设定过期时间（比如7天），然后在拦截器里校验 Token 是否有效。
下面是一个简化版的 Token 生成逻辑：
java复制// 基于 jjwt 库生成 JWT Token
public String generateToken(Long userId) {
Date now = new Date();
Date expireDate = new Date(now.getTime() + 7 * 24 * 3600 * 1000); // 7天过期
return Jwts.builder()
.setSubject(String.valueOf(userId))
.setIssuedAt(now)
.setExpiration(expireDate)
.signWith(SignatureAlgorithm.HS256, secretKey)
.compact();
}
注意这个 secretKey，一定要放到配置文件里，不要硬编码在代码中。实际部署时可以做成环境变量注入，保证密钥不会泄漏到代码仓库里。
4.2 拦截器校验登录状态
有了 Token 生成和解析的逻辑，还需要把它嵌入到请求处理流程中。Spring Boot 里最常见的做法是使用拦截器（HandlerInterceptor）。
拦截器的作用是：在请求进入 Controller 之前，先执行 preHandle 方法。这个方法里做两件事：第一，从请求头里取出 Token；第二，解析 Token，把解析出来的用户ID塞到请求上下文中，方便后面的 Controller 使用。
java复制public class AuthInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String token = request.getHeader("Authorization");
// 如果前端带过来的是 "Bearer xxx"，需要去掉前缀
if (token != null && token.startsWith("Bearer ")) {
token = token.substring(7);
}
Long userId = JwtUtil.parseToken(token);
if (userId == null) {
response.setStatus(401);
return false;
}
// 将用户ID放入ThreadLocal或request attribute中
request.setAttribute("userId", userId);
return true;
}
}
这里有几个实际踩过的坑。前端传 Token 时，很多前端框架会自动加 Bearer 前缀，而有些后端解析时没有去前缀，导致解析失败。这种问题经常是前后端联调和远程调试时才发现，明明接口在 Postman 里测的好好的，一到前端就 401。原因不一定在后端，也有可能是前端 Token 拼接方式不对。
另外一个容易忽略的点是：放行哪些路径。注册、登录这两个接口是肯定不需要 Token 的，否则用户还没登录怎么调登录接口。还有静态资源、错误页面也要放行。这个白名单配置建议单独维护一个 List，方便以后加新接口时统一处理。
4.3 日记的增删改查与分页查询
日记模块是业务核心，代码结构上我按照 Controller、Service、Mapper 三层来组织。Controller 负责接收和返回数据，Service 负责业务逻辑，Mapper 负责和数据库打交道。
新增日记的流程比较简单：前端把标题、正文、心情、天气、标签列表一起传到后端，后端先校验参数，然后从请求上下文中取出当前登录用户的ID，组装成 Diary 实体插入数据库。这里要注意标签的处理：需要先按标签名字去标签表里查，存在就用已有的，不存在就新建，然后再往中间表里插入关联记录。
日记列表的分页查询，我用的是 MyBatis-Plus 的分页插件。这里有一个很实用的优化点：列表页不需要展示完整的日记正文，只需要标题、心情、天气、创建时间和部分摘要。如果用 SELECT * 把所有正文都查出来，数据量大了之后接口会明显变慢。所以我在查询列表时只 select 必要的字段，详情页再通过 ID 查询完整内容。
java复制public PageResult<DiaryVO> getDiaryPage(Long userId, int pageNum, int pageSize) {
LambdaQueryWrapper<Diary> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(Diary::getUserId, userId)
.eq(Diary::getDeleted, 0)
.orderByDesc(Diary::getCreatedAt);
Page<Diary> page = diaryMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);
// 将实体转为VO，只保留列表页需要的字段
return convertToPageResult(page);
}
4.4 标签与日记的多对多关联
标签与日记的多对多关系，我在前面已经讲过了需要一张中间表。但在实际代码实现时，还有一个容易出错的地方：编辑关联关系不能只做新增，还要做“全量替换”。
什么意思？用户编辑一篇日记，把原来的“工作”“学习”两个标签改成“生活”“旅行”，如果你只在中间表里插入了新的关联记录，没有删除旧的关联记录，就会造成脏数据。我的做法是，在更新日记内容的同时，先 DELETE 掉这张日记在中间表里的所有关联记录，再重新插入前端传过来的标签关系。虽然多了一次删除操作，但逻辑清晰、不会出错，数据量小的时候性能影响完全可以忽略。
4.5 全文搜索的简单实现
搜索这个功能，需求上要求支持“按关键词搜索标题和正文”。最简单的实现是：
sql复制SELECT * FROM diary
WHERE (title LIKE CONCAT('%', #{keyword}, '%')
OR content LIKE CONCAT('%', #{keyword}, '%'))
AND user_id = #{userId}
但这种写法有两个问题：第一，LIKE '%关键词%' 即使加了索引也基本用不上，因为前导百分号会导致索引失效，数据量大了之后就是全表扫描，性能很差；第二，LIKE 只能做简单的子串匹配，不能处理分词、同义词、拼音搜索这些场景。
毕设项目里我用的是 MySQL 的全文索引方案。对 title 和 content 字段建 FULLTEXT 索引，然后用 MATCH...AGAINST 语法查询：
sql复制SELECT * FROM diary
WHERE MATCH(title, content) AGAINST (#{keyword} IN NATURAL LANGUAGE MODE)
AND user_id = #{userId}
但注意，全文索引对中文的支持不好，因为 MySQL 默认的分词器对中文是“单字分词”，搜出来的结果相关性很差。我的做法是在本地先对中文内容做一个简单的分词处理，把连续的英文和数字提取出来，中文则按整句去匹配，效果虽然不能跟 ElasticSearch 比，但答辩演示完全够用。
4.6 数据统计与可视化展示
日记数量按月统计，这个功能做起来比较简单，但演示效果好。思路是：查询当前用户所有未删除的日记，在 Java 代码里按年份和月份分组统计数量。
java复制SELECT DATE_FORMAT(created_at, '%Y-%m') as month, COUNT(*) as count
FROM diary
WHERE user_id = #{userId} AND deleted = 0
GROUP BY DATE_FORMAT(created_at, '%Y-%m')
ORDER BY month DESC
前端拿到这个数据之后，用 ECharts 画一个简单的柱状图或日历热力图。用户能看到自己这个月写了多少篇日记，哪些天比较勤奋。这个功能在一些日记类App里是基础功能，但在毕设里能体现你数据聚合和前端图表渲染的能力，属于性价比很高的功能点。
5. 部署上云与环境配置实操
5.1 本地环境搭建的关键步骤
在你想部署到云端之前，第一步是保证本地环境能够正常跑起来。这个过程看起来简单，但我见过太多人卡在这里。
首先是 JDK 的安装和环境变量配置。你要确认安装的是 JDK 8 而不是 JRE 8，用命令行输入 java -version 和 javac -version 分别验证运行器和编译器的版本。只装 JRE 不装 JDK 的话，Maven 编译时会直接报错说找不到 javac。
其次是 Maven 配置。除了前面提到的阿里云镜像，还有一个重要配置是本地仓库路径。默认情况下 Maven 会把你下载的依赖包存在 C 盘用户目录下的 .m2 文件夹，如果你的 C 盘空间紧张，建议在 settings.xml 里把 localRepository 改到 D 盘的目录，比如 D:\maven-repo。这个配置可以避免很多磁盘空间不足的尴尬。
然后是 MySQL 的初始化。你要为项目单独创建一个数据库，不要直接用 root 用户的默认库。在 MySQL 里执行：
sql复制CREATE DATABASE cloud_diary DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
为什么用 utf8mb4 而不是 utf8？因为 utf8mb4 是真正的四字节 UTF-8 编码，可以存储 emoji 表情和特殊字符。日记嘛，用户难免会在心情里写个表情符号，你要是用 utf8，插入数据时直接报错。
最后在 application.yml 里配置数据源：
yaml复制spring:
datasource:
url: jdbc:mysql://localhost:3306/cloud_diary?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false
username: root
password: 你的密码
driver-class-name: com.mysql.cj.jdbc.Driver
注意 serverTimezone 这个参数，必须显式指定。MySQL 8.0 的驱动默认使用服务器的时区，如果数据库服务器跟应用服务器的时区不一致，查出来的时间会差8个小时，这就是典型的时区坑。
5.2 打包构建与常见报错
本地开发没问题之后，下一步就是把项目打成可执行的 Jar 包。在项目根目录执行：
bash复制mvn clean package -DskipTests
打包过程中最常见的报错有两个。
第一个是测试类执行失败。很多同学在项目里写了几个测试类，但没有正确处理测试环境的数据源配置，打包时 Maven 会去跑测试，一跑就挂。解决方法是加 -DskipTests 跳过测试，但更好的做法是写好测试，让它能跑通过。毕设阶段为了省时间，可以暂时跳过，但你的测试类最好留一个能跑的示例，答辩时拿得出手。
第二个报错是资源文件找不到。比如你在 src/main/resources 下放了 mapper XML 文件，但如果 pom.xml 没有正确配置资源目录，Maven 打出来的包里就不会包含这些 XML 文件，运行时就会报 Invalid bound statement (not found)。这类问题的排查思路是：解压 Jar 包，看 BOOT-INF/classes 目录下到底有没有对应的资源文件。
5.3 云服务器部署流程
有了 Jar 包，部署到云服务器就不复杂了，但有几个细节会影响成败。
服务器配置方面，我建议选择 2核4G 的云主机，最低别低于 2G 内存。热词里出现过一个报错：java: outofmemoryerror: insufficient memory，这是因为 Spring Boot 应用默认启动时 JVM 会根据物理内存自动分配堆空间，如果机器内存本来就紧张，再跑一个 MySQL，内存瞬间就爆了。
解决方法是：启动 Jar 包时显式指定 JVM 内存参数：
bash复制nohup java -Xms256m -Xmx512m -jar cloud-diary.jar --server.port=8080 > app.log 2>&1 &
-Xms 指定初始堆大小，-Xmx 指定最大堆大小。2G 内存的机器，给 Java 应用分配 512M 的堆，给 MySQL 留 1G 左右，剩下的给操作系统，这样基本不会 OOM。
部署成功后，你会发现通过 IP 加端口访问不到。这个现象极其常见，原因通常不是应用没启动，而是云服务器的安全组没有开放对应的端口。不同云厂商的安全组配置位置不一样，但逻辑是一样的：需要在控制台添加入方向规则，允许 TCP 8080 端口的访问。
如果你不想用 IP 加端口这么裸奔的方式，更推荐的方案是用 Nginx 做反向代理。前端打包成静态文件放到 Nginx 的 html 目录，后端接口通过 /api 路径转发到 Java 服务。这样不仅解决了跨域问题，还能通过 Nginx 配置 SSL 证书实现 HTTPS 访问，整个项目的完成度会上一个档次。
6. 常见问题排查与避坑实录
6.1 Spring Boot 版本太高引发的问题
热词里有“springboot版本太高”和“springboot jdk1.8打包到docker desktop”，这两个放一起说很有代表性。
很多同学新建项目时图省事，直接选最新版 Spring Boot 3.x，然后发现本地 JDK 8 编译不过，报错信息类似 java: invalid source release: 17。这时候就开始怀疑人生了，明明代码没写错，怎么就是起不来。
我的建议是：如果你不是要研究新特性，不要盲目追新。Spring Boot 2.7.x 是 2.x 的最终版本，稳定、资料多、兼容 JDK 8，是毕设项目最稳妥的选择。框架选型的第一原则永远是“满足需求的前提下选最稳的”，不是“选最新的”。
如果你非要尝试 Spring Boot 3.x，也不拦你。但你得确保三件事：JDK 升级到 17 或更高；所有第三方依赖都能兼容 Jakarta EE 9 的命名空间；你的数据库驱动、Redis 客户端等中间件版本都够新。任何一个环节不匹配，排查起来都非常痛苦。
关于 Docker 部署的问题，热词里提到 jdk1.8 打包到 docker desktop，这个场景其实就是在 Spring Boot 2.7.x + JDK 8 的环境下，用 Dockerfile 把应用做成镜像。我给的模板是这样：
dockerfile复制FROM openjdk:8-jdk-alpine
COPY target/cloud-diary.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]
这是最简单也最稳的方式，因为基础镜像本身就带了 JDK 8，不存在环境不一致的问题。
6.2 数据库连接池耗尽
项目运行一段时间后，突然所有请求都卡住不动了，后台日志报 Connection is not available, request timed out after 30000ms。这个错误的含义是：数据库连接池里的连接全被占满了，新请求拿不到连接。
最常见的原因是长事务导致连接不释放。比如一个事务里先查了一堆数据，然后在事务里调用了外部 HTTP 接口，这个外部接口又慢又卡，事务一直不提交，连接就一直占用着。解决思路是：事务控制一定要精细，能不开就不开，查询操作不要加事务；如果确实有多个写操作需要原子性，也要尽量缩短事务执行时间，绝对不要在事务里面做远程调用。
排查连接池问题，可以在配置里打开相关监控：
yaml复制spring:
datasource:
hikari:
maximum-pool-size: 20
connection-timeout: 30000
观察日志里的活跃连接数和使用率，就能定位到底是不是连接池被打满了。
6.3 前后端联调时的跨域问题
前后端分离架构下，跨域（CORS）问题几乎一定会遇到。前端的地址是 http://localhost:5173，后端的地址是 http://localhost:8080，浏览器出于同源策略，会直接拦截跨域的 AJAX 请求。
解决跨域最通用的方案是在后端配置跨域过滤器。Spring Boot 里推荐直接实现 WebMvcConfigurer 接口：
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 和 allowedOrigins 的区别。如果配置了 allowCredentials(true)，allowedOrigins 不能配置为 *，必须写具体域名，否则会有安全限制；而 allowedOriginPatterns 支持通配符匹配，可以配合 allowCredentials 使用。
6.4 远程调试的配置方法
热词里出现“clion远程调试”和“visual studio 2026远程调试”，虽然那是 C/C++ 领域的工具，但远程调试的思路对所有编程语言是通用的。对于 Java 项目，远程调试主要是用 JVM 的调试端口机制。
在部署服务器的启动命令中加上：
bash复制java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 -jar cloud-diary.jar
然后在本地 IDEA 中配置一个 Remote JVM Debug 的运行配置，Host 填服务器 IP，Port 填 5005，就能在本地打断点、看变量、逐步调试了。
注意 address 参数如果写成 *:5005，这是在 JDK 9+ 中的写法，JDK 8 中直接写 5005 即可。另外，远程调试端口千万不要对外开放到公网，否则有被攻击的风险。调试完第一时间关掉这个端口，只保留应用正常服务的 8080 端口。
远程调试在实际开发中最大的价值，是解决"本地跑得好好的，到服务器上就挂了"这类环境问题。比如本地连的是本地 MySQL，服务器连的是云上 MySQL，两边数据不一样，你怎么知道是数据问题还是代码问题？断点一打，看到实际参数值，问题就清楚了。
6.5 时间字段的时区问题
这是一个非常隐蔽又常见的坑。数据库里存的 created_at 是 2025-01-15 14:30:00，但接口返回给前端变成了 2025-01-15 06:30:00，整整慢了8个小时。
原因就是前面提到的 serverTimezone 参数没配对，或者 Java 应用与数据库服务器的时区不一致。解决方案统一一下：
- 数据库连接 URL 里明确指定 serverTimezone=Asia/Shanghai
- Java 应用启动时，通过 JVM 参数统一时区：-Duser.timezone=Asia/Shanghai
- 数据库的日期类型字段用 datetime 而不是 timestamp。timestamp 在 MySQL 内部会转换为 UTC 存储，再按会话时区转回，多了一道转换就容易出错。
7. 项目讲解思路与答辩经验
7.1 如何给答辩老师讲清楚架构
做完了项目，最后一步是要能讲出来，讲得让人明白。我通常建议学弟学妹按照“从外到内”的顺序讲：
先讲用户视角：用户打开系统，注册登录，写日记，打标签，搜索日记，查看统计图表，导出数据。这个环节的目的是让老师知道你这个系统“是干什么的”。
再讲技术视角：前端用 Vue 3 + Element Plus，后端用 Spring Boot，数据库用 MySQL，鉴权用 JWT Token，部署到云服务器。这个环节要突出你的技术选型思路，可以重点讲讲为什么选择 JWT 而不是 Session，为什么用逻辑删除而不是物理删除。
最后讲架构视角：整个系统的请求流程是一条链路——浏览器发请求，Nginx 接收静态页面并把 API 请求转发到 Java 服务，Java 服务的拦截器先校验 Token，通过后进入 Controller，再到 Service 层处理业务逻辑，最后通过 MyBatis 操作 MySQL 数据库。这个链路图你要能徒手画出来。
7.2 复盘一下这套方案整体做下来有什么感受
最后聊一点我个人的体会。这套云端日记本系统，从需求分析到最终部署上线，整个流程走下来，它看起来只是一个普通的 Web CRUD 应用，但其中的每一个环节——数据库设计时的字段取舍、鉴权方式的选型、部署时的版本搭配、远程调试的排查思路——背后都有实实在在的工程考量。
我做过的类似项目很多，最大的感受是，不要小看任何“简单”的系统，再简单的需求，只要你的标准是“上线可用而不只是本地能跑”，它就能逼着你去面对大量课本之外的真实问题。比如版本兼容、内存规划、跨域处理、时区陷阱，这些东西没有一个写在教学大纲里，但每一个都在实际开发中真实地出现过。
如果你是正在做这个选题，或者正打算做类似的后端项目，我建议你按这套思路一步步来，别急着跳步。先把环境搭稳，再把表设计清楚，代码一模块一模块地写，最后部署上线，你会比那些只在本地跑通就完事的同学收获多得多。