Spring Boot 项目实战日：代码重构、新功能开发与环境搭建

发表于 分类于

一篇记录同一天内三个 Spring Boot 项目的实战工作：图书管理系统的 Controller 层重构与分支合并策略、毕业设计图书评分评论功能的全流程开发，以及物联网项目本地 Nacos + TDengine 环境的搭建验证。

前言

2026 年 4 月 7 日是个忙碌的开发日。手头同时在推进三个 Spring Boot 项目：一个图书管理系统的代码重构、一个毕业设计的新功能开发、一个物联网项目的本地环境搭建。三件事看起来互不相干，但串起来恰好是一条完整的后端开发链路——从环境就绪到代码编写，再到结构优化。

本文按项目维度分别记录，提炼每件事的关键决策和经验。

一、图书管理系统：Controller 层重构

1.1 背景

图书管理系统的 Controller 层积累了大量重复逻辑：鉴权校验散落在各个接口、封面上传在多处复制粘贴、公共工具类没有统一收口。这轮工作的目标是”公共工具与基础抽象收口”，先不碰页面结构，只做后端低风险的 cleanup。

1.2 重构内容

在隔离的 git worktree 中完成了三个 Task：

Task 提交 核心改动
UserApplicationController 收口 a7ee203 新增 AuthGuard，接口改用 DTO 绑定，收口管理员鉴权
封面上传公共化 e8bbd03 抽取 CoverUploadService，消除 BookController 和 StudentBookController 的重复上传逻辑
LendRecordController 读侧收口 54b4343 整理读接口公共校验，不碰写路径

关键设计决策：只动读接口，不动写路径。这样把风险控制在最小范围，写路径的收口留给后续迭代。

Controller 重构分层架构
图 1：Controller 层重构——公共服务下沉与鉴权横切

1.3 分支合并策略

这里有个值得记录的决策过程。当时手头有两个分支：

  • 代码分析和优化：用户明确要求合并的分支
  • controller-cleanup-task1：在 worktree 中完成的重构分支

最终策略：

  1. 先修基线测试：代码分析和优化 分支上有一个 DashboardControllerTest 失败，根因是 SysConfigMapper mock 缺失。补齐后新增两个降级场景测试
  2. 合并并验证：代码分析和优化 合入 main，跑通 38 tests, 0 failures
  3. cleanup 暂不合入：controller-cleanup-task1 保留在 worktree，等单独审查后再合并
1
2
3
# 最终合并结果
f18d944 Merge branch '代码分析和优化'
bccb1c5 fix dashboard visit count test coverage

这个策略的核心思路：先合用户要求的，cleanup 作为独立批次后续跟进。避免把两件事混在一起增加审查复杂度。

二、毕业设计：图书评分与评论功能

2.1 功能设计

为小学图书管理系统新增完整的评分与评论体系：

  • 评分：归还图书后可打 1-5 星
  • 评论：可选填文字评论（最多 500 字）
  • 统计：图书列表展示平均评分和评价人数
  • 管理：管理员可删除不当评论（软删除）

2.2 API 设计

4 个 REST API，职责清晰：

API 方法 路径 权限
提交评论 POST /review 登录 + 借阅记录验证
评论列表 GET /review/book/{isbn} 公开，分页
评分统计 GET /review/book/{isbn}/stats 公开
删除评论 DELETE /review/{id} 管理员

2.3 代码审查发现的问题

功能写完后做了一轮代码审查，发现两个重要问题：

安全漏洞（commit 06f8c4f）：

  • submit() 接口无 Token 校验，任何人都能提交评论
  • delete() 接口无权限校验，任何人都能删除评论
  • 修复：添加登录验证和管理员角色校验

性能问题（commit 16131cc）：

  • stats() 在 Java 内存中计算平均分 → 改为 SQL 聚合查询
  • 分页参数手动验证 → 改用 QueryUtils.createPage() 工具方法
1
2
3
4
5
6
7
8
// SQL 聚合替代内存计算
@Select("""
    SELECT COUNT(*) as total_count,
           AVG(rating) as avg_rating
    FROM book_review
    WHERE isbn = #{isbn} AND deleted = 0
    """)
ReviewStats selectStatsByIsbn(@Param("isbn") String isbn);

这两轮审查修复说明：新功能开发完成后，安全和性能审查不可省略。尤其是鉴权和数据聚合，很容易在”先跑通”阶段被忽略。

图书评分评论功能流程
图 2：图书评分评论功能——从还书到统计的完整流程

三、物联网项目：本地环境搭建

这套物联网项目的本地启动方案并非从零搭建，而是在已有的 BladeX-Links 本机启动清单基础上增加 Nacos：

1
BladeX-Links 本机启动清单 + 本地 Nacos = 当前物联网项目本机启动链路

共享的基础设施：MySQL + Redis + TDengine。唯一新增的是 Nacos 配置中心/注册中心。

3.2 Nacos 配置

复用之前修复过的本地解压版 Nacos，不依赖 Docker：

配置项 值
API 地址 http://starviewnacos.com:8340/nacos/
控制台 http://localhost:8380/
启动模式 standalone + embeddedStorage
hosts 映射 127.0.0.1 starviewnacos.com

关键点：hosts 文件必须配置域名映射，否则 Spring Boot 启动时无法连接 Nacos。

3.3 TDengine 配置

沿用本地 3.0.7.1 版本方案：

配置项 值
REST 地址 http://127.0.0.1:6041/rest/sql
数据库名 links
启动命令 taosd + taosadapter

验证方式简单直接：show databases; 能看到 links 库就算就绪。

3.4 推荐启动顺序

1
2
3
4
5
1. MySQL    → 数据源
2. Redis    → 缓存
3. TDengine → 时序库
4. Nacos    → 配置中心 + 注册中心
5. 业务服务 → 最后启动

按这个顺序，每个服务启动时它依赖的基础设施都已就绪，避免因连接超时导致启动失败。

本地环境启动依赖链
图 3：物联网项目本地启动依赖链——Nacos 是新增项

经验总结

回顾这三件事，提炼几个共通的要点：

  • 隔离开发降低风险：Controller cleanup 在 worktree 中进行，不影响主分支，验证通过后再考虑合入
  • 分支策略要清晰：用户要求的合并和自主的重构分开处理，审查负担不叠加
  • 新功能审查不可省：鉴权校验和数据聚合方式是最容易遗漏的两类问题
  • 环境搭建要复用：不要每次都从零配，在已有方案上做增量是最快的
  • 启动顺序有讲究：先基础后业务，让每个服务启动时依赖已就绪

结语

一天推三个项目听起来紧张，但每个项目都只聚焦一个明确的切面：重构是收口公共逻辑、新功能是完整实现并过审、环境是复用已有方案做增量。小步推进，每个切面都不贪多，反而效率最高。