Spring Boot实战：构建16+8轻断食打卡系统

如果你最近在琢磨16+8轻断食的落地执行，又在用Spring Boot练手后端开发，那这个基于Spring Boot的“16+8轻断食打卡程序”应该正好对上你的胃口。它本质上是一个健康管理类Web应用：用户可以注册登录、设置每天8小时进食窗口、一键记录每次进食时间，系统自动算出距离上次进食是否已满16小时，还能按日历、按月统计打卡完成率。整套项目从数据库设计、后端接口到基础前端页面都能直接跑通，源码整理后也不挑机器，适合Java后端初中级水平的开发者拿来参考，产品经理和测试同学拿来当完整业务样例也很合适。

这类项目看着不大，但把时间窗口计算、连续打卡统计、定时提醒这些逻辑都塞进去之后，其实挺考验基本功的。下面我从需求拆解到核心代码实现，再到底层问题排查，把我实际做这个项目的完整思路和踩坑经验展开说清楚。

1. 16+8轻断食与系统需求拆解

1.1 轻断食的业务本质与系统切入点

16+8轻断食不是节食，它是在一天内把进食时间压缩到8小时以内，其余16小时保持禁食状态。比如中午12点到晚上8点之间正常吃饭，晚上8点到第二天中午12点之间只喝水、黑咖啡这类零热量饮品。这段时间里身体胰岛素水平下降，糖原逐渐消耗完，脂肪供能比例升高，长期坚持有助于控制体重和改善代谢指标——当然，具体效果因人而异，执行前也应该评估自身健康状况。

那为什么需要程序来管理这件事？因为人脑对时间的记忆非常不可靠。你可能周五晚上临时聚餐吃到9点半，第二天中午又提前到11点半吃饭，窗口一变，16小时起点也跟着变。靠大脑推算“上次进食到现在有没有16小时”，十次有八次会算错。这个程序的核心价值就是替用户记住“最后一餐时间”，并自动判断当前处于禁食中还是进食窗口内。

1.2 功能需求池梳理

我在设计这个程序之前，没有直接写代码，先列了一张需求池，把产品功能按优先级排好。很多新手做项目喜欢动手就建表，结果做着做着发现字段不够、逻辑打架，返工成本特别高。提前做需求梳理，后面开发速度反而更快。

功能模块	功能点	优先级	说明
用户模块	注册、登录、退出	P0	用手机号或用户名注册，密码加密存储
断食配置	设置每日进食窗口起止时间	P0	默认12:00-20:00，可自由修改
打卡记录	记录每次进食时间、备注	P0	支持当天多次记录
断食状态计算	显示当前是“禁食中”还是“窗口期”	P0	依据最近一条进食记录推算
日历统计	当月每日完成情况展示	P1	完成标准是禁食时长达到16小时
连续天数统计	显示连续达标天数	P1	对用户有正向激励作用
定时提醒	断食满16小时时提醒	P2	用定时任务实现，掌握思路即可

P0是核心闭环：用户配置窗口、记录进食、系统反馈断食时长。P1和P2是体验增强项。如果把P0都做完，项目已经可以运行了；P1-P2做完，项目才真正像一个能给别人用的产品。

1.3 典型使用场景与人机交互设计

我设想了两个典型场景来约束接口设计。场景一是新用户注册后第一次使用：用户设置“中午12点-晚上8点”为窗口，12点半吃了一顿午饭并打卡，系统显示“距离上次进食0.5小时，预计16小时后，即次日凌晨4点半完成本轮断食”。看到这个时间轴之后，用户再去吃晚饭心里就踏实了。

场景二是第二天早晨：用户起床打开首页，系统显示“当前处于禁食中，已禁食10小时32分钟，距离达成16小时目标还剩5小时28分钟”。这个显示逻辑并不复杂，但因为涉及“跨天”“多次进食”“窗口修改”这些边界情况，我在计算逻辑上花的时间其实最多。后面第3章会专门拆解。

2. 技术选型与整体架构设计

2.1 为什么选Spring Boot而不是更简单的方案

这种体量的项目，用纯Servlet + JSP也能写出来，甚至用Python Flask十分钟就能搭个原型，但我不建议这么做。原因是这个项目的主要价值不只是“跑起来”，而是让你理解一个标准企业级Java项目的骨架：分层架构、依赖注入、统一异常处理、定时任务、权限控制。Spring Boot把这些东西全部封装成“开箱即用”的Starter，既能让你聚焦业务逻辑，又保留了深入底层扩展的空间。

Spring Boot还有两个实际优势：第一，内置Tomcat，打包成jar就能直接跑，不像传统SSH项目要单独装Tomcat、配置一堆XML；第二，生态太成熟了，做鉴权有Spring Security + JWT，做持久层有JPA或MyBatis，做接口文档有Knife4j，几乎每个需求都能找到趁手的组件。

2.2 技术栈选型与理由

项目实际采用的技术栈如下：

层次	技术选型	选型理由
后端框架	Spring Boot 2.7.x	稳定版本，Java 8/11均可运行
持久层	Spring Data JPA	单表操作多、实体映射简单，适合中小型项目快速开发
数据库	MySQL 8.0	主流关系型数据库，本地环境容易搭建
测试数据库	H2	单元测试和演示时无需安装MySQL，内存模式启动即用
安全认证	JWT + BCrypt	无状态认证，适合前后端分离场景
定时任务	Spring @Scheduled	无需额外引入消息队列，满足轻量级提醒需求
前端	Bootstrap + Vue（CDN引入）	减少构建成本，后端页面直接托管静态资源

有人可能会问：为什么不用MyBatis-Plus？我用JPA是因为这个项目的查询以“按用户和日期查打卡记录”为主，单表查询居多，JPA的Repository接口方法名推导能省掉大量SQL。如果表关联复杂、SQL需要精细调优，那确实应该换MyBatis。选型没有绝对的对错，但你要能说出自己为什么这么选——这也是面试官常问的问题。

2.3 数据库设计：三张表把业务串起来

这个项目的核心表一共三张：用户表、断食配置表、打卡记录表。断食配置本来可以直接做成用户表里的一列“start_time”和“end_time”，但断食窗口属于“用户多次修改的历史”，以后升级可能要做数据分析，所以我单独拆了一张表，保留修改记录。

用户表字段如下：

字段名	类型	说明
id	bigint	主键，自增
username	varchar(50)	登录用户名，唯一
password	varchar(100)	BCrypt加密后的密码
nickname	varchar(50)	昵称，默认同用户名
height	decimal(5,1)	身高，厘米，可选填
weight	decimal(5,1)	体重，公斤，可选填
create_time	datetime	创建时间
update_time	datetime	更新时间

打卡记录表是整张表里最关键的设计，业务逻辑几乎都围绕它展开：

字段名	类型	说明
id	bigint	主键
user_id	bigint	用户ID，普通索引
eaten_at	datetime	进食时间，核心计算依据
note	varchar(255)	备注，比如“午餐-鸡胸肉沙拉”
create_time	datetime	记录创建时间

这张表最核心的字段是eaten_at，它表示“这一餐是什么时候吃的”。注意，它和create_time有可能不一致。比如用户今天上午想补录昨天晚上的晚餐，eaten_at应该填昨晚20:00，而create_time是今天。计算断食状态时，必须用eaten_at而不是create_time。这个坑我在第一阶段代码评审时就踩到了，一开始用create_time，结果补录一餐后断食计时完全错乱。

断食配置表则记录用户当前有效的窗口起止时间和生效时间，查询时取最新一条即可。

2.4 分层架构与工程目录

整个工程按标准的Controller-Service-Repository三层来组织，包结构如下：

com.example.fasting ├── config // 配置类：WebMvcConfig、CorsConfig ├── controller // 接口层：AuthController、RecordController、StatsController ├── dto // 入参出参对象 ├── entity // 实体类：User、FastingConfig、MealRecord ├── repository // 数据访问层，继承JpaRepository ├── service // 业务逻辑层 │ └── impl // 接口实现 ├── task // 定时任务：提醒扫描任务 ├── util // 工具类：JwtUtil、TimeUtil └── exception // 自定义异常与全局异常处理器

分层不是形式主义，它的核心价值是“隔离变化”。比如以后要把时间计算规则从“固定16小时”改成“按性别身高体重动态调整目标时长”，你只需要改Service层的计算逻辑，Controller和数据库层完全不用动。这种边界清晰的工程结构，哪怕项目只有几千行代码，也能让人在一分钟内找到要改的地方。

3. 核心功能实现详解

3.1 用户注册登录与JWT鉴权

用户注册接口接收用户名、密码、昵称三个参数。密码不能明文入库，我使用Spring Security自带的BCryptPasswordEncoder做哈希加密，每次调用encode()会生成随机盐，所以即使用户两次设置相同密码，密文也不同，有效抵御彩虹表攻击。

登录成功之后签发JWT令牌，把userId嵌入令牌中，设置7天有效期。后端写一个拦截器，解析请求头里的Authorization字段，校验令牌合法后把userId放入ThreadLocal或请求上下文，供后续接口使用。

实际项目中我更推荐把JWT工具类单独封装，不要散落在Service里。我的JwtUtil包含三个方法：generateToken(userId)、parseToken(token)、isTokenValid(token)，这样Controller层代码会非常干净。

3.2 断食状态计算：这个逻辑是最核心的难点

计算断食状态是整个项目最值得讲清楚的部分。需求是：给定一个用户，任意时刻判定他当前处于“禁食中”还是“进食窗口内”，并计算距离下一轮断食完成还剩多久。

计算规则定为：用户这一天的有效进食窗口为[startTime, endTime]，比如12:00到20:00。如果当前时间落在窗口内，则状态为“进食窗口内”。如果当前时间落在窗口外，则状态是“禁食中”，禁食起点从窗口结束时间开始计算，但问题是——如果用户最后一餐吃晚了（比如20:30才吃完），禁食起点就应该从20:30重新算，不能机械地用endTime。

所以更准确的算法是：先取出用户最近一条eaten_at时间，记为lastMealTime。如果lastMealTime在今天的窗口结束时间之前，则禁食起点取窗口结束时间；如果lastMealTime晚于窗口结束时间，则禁食起点直接取lastMealTime。当前时间减去禁食起点，就是已禁食时长；用16小时减去已禁食时长，就是剩余时间。

这里有一个容易忽略的边界：如果当前时间是晚上21:00，用户最后一次进食是当晚19:30，按说还没到20:00窗口结束，此时仍然算窗口内，不应该进入禁食。很多初版实现直接用“当前时间是否晚于endTime”来判断，忽略了19:30这个点仍在窗口内的事实，导致晚上7点半到8点之间打卡后立即显示“已进入禁食”，明显不合理。

我在Service层写了一个calculateFastingStatus(userId, LocalDateTime now)方法，返回一个状态对象，包含status（枚举：FASTING / WINDOW）、fastedHours、remainingMinutesToGoal、nextMealWindowStart这几个字段。这样前端就能直接渲染卡片信息，不需要再做任何时间计算。

3.3 打卡记录接口与防重逻辑

记录一次进食的接口长这样：

@PostMapping("/api/record") public ApiResult<Long> addRecord(@RequestBody RecordCreateDTO dto, @RequestAttribute("userId") Long userId) { MealRecord record = new MealRecord(); record.setUserId(userId); record.setEatenAt(dto.getEatenAt() == null ? LocalDateTime.now() : dto.getEatenAt()); record.setNote(dto.getNote()); mealRecordRepository.save(record); return ApiResult.ok(record.getId()); }

一个细节是：dto.getEatenAt()允许前端传入，这样可以补录之前的餐食，但为了防止用户频繁误点造成同一分钟生成多条重复记录，我在Service中加了一个防重校验：在同一用户下，查询最近一条记录的eaten_at，如果与新增记录时间差小于5分钟，就抛出一个业务异常“已经记录过该时段的进食，如需修改请删除后重新记录”。

这个防重逻辑可能有人觉得多余，但实际使用中用户反复点击按钮的概率非常高，不做防重的话打卡日历上的数据会很脏。

3.4 月度汇总与打卡日历统计

日历统计要回答的问题很直观：这个月哪些天完成了16小时断食？连续坚持了几天？

计算“某天是否达标”不能光看这一天有没有打卡，而要判断“这一天结束时，是否正处于一个完整断食周期中”，或者“今天是否有某一轮断食持续了至少16小时”。最简单可靠的算法是：取出该用户当月所有打卡记录，按时间排序后，从每条记录开始向后推算16小时，如果这16小时的区间完整落在同一天，或者跨天后，下一条打卡记录的时间晚于“上次进食+16小时”，都算达标。

但这样做代码复杂度偏高了。我换成了更工程化的思路：所谓“某天完成断食”，定义是——从这天窗口结束时间开始，到第二天窗口开始时间之前，用户至少有一次连续16小时没有进食记录。数据层面就是：查询当天及下一天的进食记录，检查是否存在两个相邻记录之间的时间间隔≥16小时，且该间隔横跨了前一天的结束时间。

代码上我用SQL处理这个查询，比Java内存遍历更清晰：

SELECT DATE(eaten_at) AS day, TIMESTAMPDIFF(HOUR, MIN(eaten_at), MAX(eaten_at)) AS max_interval FROM meal_record WHERE user_id = ? AND eaten_at BETWEEN ? AND ? GROUP BY DATE(eaten_at)

对于“连续达标天数”，我在Service中遍历当月每天的达标布尔值，从今天往前数，连续为true的天数就是当前连续完成天数。这是典型的O(n)逻辑，写起来简单，效果却很直观。

3.5 定时提醒：断食满16小时自动通知

定时任务用Spring自带的@Scheduled就能搞定。我在每分钟整点执行一次扫描任务，查所有配置了窗口且当天有进食记录的用户，计算当前已禁食时长，如果刚好跨越16小时且用户开启了提醒开关，就向用户发送站内信或在日志中输出一条提醒记录。

@Component public class FastingRemindTask { @Scheduled(cron = "0 0 * * * *") // 每小时整点执行一次，频率够用且不打爆数据库 public void scanAndRemind() { // 查询当天正处于禁食状态且已禁食时间超过15.5小时的用户 // 生成提醒消息，实际项目中可接入邮件或短信渠道 } }

提醒功能的难点不在于定时任务本身，而在于避免重复提醒。一个用户禁食16小时的状态会持续好几个小时，如果每分钟扫一次且不加标志位，他会收到几十条提醒。我采用的方案是：把“已提醒过的断食周期”记录到一张提醒日志表，主键是user_id + fasting_cycle_start_time，这样同一个断食周期只能触发一次提醒。这个思路比简单的lastRemindTime更严谨，因为用户可能一天有多个断食周期。

3.6 统一异常处理与参数校验

真实项目里不能让异常堆栈直接抛给前端。我写了一个GlobalExceptionHandler，用@RestControllerAdvice捕获所有异常，把业务异常转成JSON错误码，未知异常统一返回“系统繁忙，请稍后再试”。

参数校验用JSR 303注解放在DTO字段上，比如用户名不能为空、密码最少6位、窗口起止时间不能相等。这些看似基础的小事，在联调阶段能省掉一半的口水。

4. 实操：从零搭建项目并跑通

4.1 环境准备与工程初始化

我用的是Spring Boot 2.7.18，要求JDK 8及以上，推荐直接用JDK 11，本地提前安装Maven 3.6+和MySQL 8.0。初始化工程可以直接用Spring Initializr网页版，勾选Spring Web、Spring Data JPA、MySQL Driver、Validation这几个依赖生成基础包，耗时一分钟。

生成的骨架里包含主启动类，我习惯在启动类上再加一个@EnableScheduling注解，否则后面写定时任务不会生效。同时注意@SpringBootApplication默认只扫描启动类同级及子包，所以新建的controller、service包都要放在启动类所在包下面。

4.2 Maven依赖与核心配置

下面是我使用的application.yml核心配置片段，注释部分按实际环境调整：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/fasting_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: update show-sql: true jwt: secret: your-secret-key-should-be-at-least-32-bytes-long expire-days: 7 fasting: default-start: "12:00" default-end: "20:00" target-hours: 16

jwt.secret这个配置要注意，生产环境必须放到环境变量或配置中心，不要硬编码提交到代码仓库。fasting.target-hours我抽成配置项而不是写死在代码里，理由是未来可能针对不同用户提供14/16/18小时多档目标，只要改配置就能扩展。

数据库连接串里必须加上serverTimezone=Asia/Shanghai，否则本地MySQL默认的时区和JVM时区不一致，LocalDateTime读出来会差8小时。这个问题特别隐蔽，排查起来也很花时间，后面第5章会细讲。

4.3 核心实体与接口示例

用户实体部分字段示例如下：

@Entity @Table(name = "t_user") public class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(nullable = false, unique = true, length = 50) private String username; @Column(nullable = false, length = 100) private String password; @Column(length = 50) private String nickname; private LocalDateTime createTime; private LocalDateTime updateTime; }

这里我用了t_user作为表名而不是user，是因为user在MySQL里是系统保留关键字，直接建表会报错。这种细节只有实际跑一次SQL才会注意到。

Controller层的关键是保持轻薄。以一个获取断食状态的接口为例：

@RestController @RequestMapping("/api/status") public class StatusController { @Resource private FastingStatusService statusService; @GetMapping("/current") public ApiResult<FastingStatusVO> current(@RequestAttribute("userId") Long userId) { return ApiResult.ok(statusService.getCurrentStatus(userId)); } }

真正的计算逻辑放在Service实现类里，这样便于单测。我在开发阶段给Service写了好几个直接调用内部方法的单元测试，专门验证“晚上8点整打卡”“凌晨0点查询”“补录昨晚进食”等边界场景。

4.4 数据库初始化与演示数据

由于JPA配置了ddl-auto: update，启动时Hibernate会自动建表，省去手工执行建表SQL的麻烦。但你作为项目参考，还是需要一份SQL脚本方便导入演示数据：

INSERT INTO t_user (username, password, nickname, create_time, update_time) VALUES ('demo', '$2a$10$7fK...', '演示用户', NOW(), NOW()); INSERT INTO t_fasting_config (user_id, start_time, end_time, effective_date, create_time) VALUES (1, '12:00', '20:00', '2025-01-01', NOW()); INSERT INTO t_meal_record (user_id, eaten_at, note, create_time) VALUES (1, '2025-01-06 12:30:00', '午餐', NOW()), (1, '2025-01-06 19:45:00', '晚餐', NOW());

注意演示用户的密码字段我写的是BCrypt密文，你不能直接手动改123456，否则登录永远失败。密码这类数据只能通过注册接口生成，手工伪造密文很容易给自己埋坑。

4.5 联调、打包与部署

前端页面上，我建议本地直接用Vue的CDN方式加Bootstrap写一个单页应用，不需要Node环境，打开一个index.html就能联调。页面主要有三个区块：当前断食状态卡片、打卡按钮与备注输入框、当月日历热力图。

打包发布时执行mvn clean package，生成的可执行jar在target/目录下，用以下命令启动：

java -jar fasting-app.jar --spring.profiles.active=prod

生产环境的配置我放到application-prod.yml里，使用独立的数据库账号和密码，同时把show-sql设为false、ddl-auto设为validate，避免上线后Hibernate自动改表结构造成事故。这一套流程走完之后，前端静态资源既可以打成独立包部署，也可以直接拷到Spring Boot的static目录下，二者效果一致。

5. 常见问题与排查技巧实录

5.1 时间总差8小时：LocalDateTime与MySQL时区

这个问题几乎每个用Spring Boot + MySQL的开发者都会遇到。表现为：数据库里存的数据时间正常，但接口返回的时间比实际时间晚8小时或早8小时，或者前端显示几小时后才完成断食。

原因有两个层面：第一，JDBC驱动连接串里没加serverTimezone，导致驱动用了系统默认时区；第二，Java 8的LocalDateTime本身不带时区，但数据库会话有时区会做隐式转换。解决办法是连接串统一加serverTimezone=Asia/Shanghai，并且实体字段全部用LocalDateTime，不要混用Date和LocalDateTime。混用的后果很严重——有一天旧代码用Date写入，新代码用LocalDateTime读取，转换逻辑不一致，时间就错乱了。

5.2 数据库乱码与字符集不匹配

如果你看到接口里传入的中文备注变成了问号，多半是数据库表和连接的字符集不一致。MySQL建库时要用utf8mb4而不是utf8，因为utf8mb4才能完整支持中文和生僻字。连接串里已经有characterEncoding=utf8，但还不够，需要确认表本身是utf8mb4：

ALTER TABLE t_meal_record CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

5.3 跨域请求被浏览器拦截

前后端分离开发时，前端运行在8081端口，后端8080端口，浏览器会发起跨域请求。如果后端不处理跨域，前端浏览器控制台会报CORS错误。我写了一个配置类统一处理：

@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改成实际前端域名，否则接口等于裸奔，谁都能跨域调用。很多新手觉得跨域配置是“加上就完事”的样板代码，其实它也是安全边界的一部分。

5.4 定时任务不执行或重复执行

定时任务不执行，最常见的两个原因：主启动类没有加@EnableScheduling；或者用的Spring Boot版本比较高，默认线程池只有一个线程，如果任务里某个环节阻塞，后面的任务全被卡住。我建议在配置类里显式定义一个定时任务线程池：

@Configuration public class SchedulingConfig implements SchedulingConfigurer { @Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { taskRegistrar.setScheduler(Executors.newScheduledThreadPool(5)); } }

多实例部署时还要注意重复执行问题：两台服务器同时跑定时任务，会发出两条提醒。轻量级方案是只在一台机器开启任务，或用数据库分布式锁。这个项目单机跑，我直接用声明式注释说明“集群环境需引入分布式锁”，避免读者把单机逻辑直接搬到云上。

5.5 问题排查速查表

症状	可能原因	快速检查步骤
登录接口报401	JWT密钥不一致或令牌过期	检查jwt.secret是否变了，确认Header里Authorization格式
打卡日历有天缺数据	补录记录时eaten_at传入空	检查前端传入时间字段是否解析成功
断食状态计算不准	最近一条记录时间被重复修改	查看t_meal_record表的eaten_at排序，确认最新记录
页面中文测出来是乱码	数据库字符集不是utf8mb4	执行SHOW CREATE TABLE查看字符集设置
中文备注提交后长度报错	字段长度不足	varchar字段建议至少255，避免中文占多字节问题
定时任务整点没跑	未加@EnableScheduling	看控制台启动日志是否有scheduled线程启动

排查技巧方面，我最常用的手段是在Service层关键方法里加临时日志，打印传入参数和计算结果。比如断食状态计算函数，我会打印lastMealTime、windowStart、windowEnd、computedStartTime、remainingMinutes这几个中间值，这样一看日志就知道是计算逻辑错还是数据错，根本不用打断点去Debug。

写在最后的个人体会

这个项目给我最大的收获不是框架语法本身，而是“时间计算类”业务的设计敏感度。轻断食这个概念听起来很简单，一旦落到系统里，就涉及到跨天、补录、重复进食、窗口变动等各种边界情况。做产品的乐趣恰恰在于：你能把一个生活里的模糊习惯，转化成一套确定性的规则，并用代码把它自动化。如果你也想通过做项目练手，我强烈建议不要只照着教程抄代码，而是像我这样先画需求池、列边界场景、再动手写实现。踩着坑写出来的代码，和对着文档敲出来的代码，经验沉淀完全不一样。最后再提醒一句：轻断食是否适合自己要听专业医生的建议，代码逻辑可以严谨，健康决策更要严谨。