应使用包装类型（如Integer）、@Enumerated(EnumType.STRING)、LocalDateTime配合审计注解，外键用@ManyToOne(fetch = FetchType.LAZY)，查询方法需注意null值导致的SQL逻辑错误。
任务实体类怎么定义才兼顾JPA映射和业务逻辑
直接用 @Entity 标注类、@Id 标注主键是基础，但容易忽略的是字段的可空性与数据库约束的一致性。比如状态字段用 Integer 而不是 int，否则 JPA 无法存 NULL；又比如创建时间用 @CreationTimestamp 配合 @Column(updatable = false)，避免手动赋值出错。
常见错误：把 Task.status 设为 int，结果数据库里允许 NULL，插入时抛 ConstraintViolationException；或者没加 @Enumerated(EnumType.STRING)，导致状态存成序号（0/1），后期加枚举项就乱序。
-
status字段推荐用String或带@Enumerated的枚举类，别用裸数字 - 时间字段统一用
LocalDateTime，配合@CreatedDate/@LastModifiedDate（需启用@EnableJpaAuditing） - 外键关联（如所属用户）用
@ManyToOne(fetch = FetchType.LAZY)，避免 N+1 查询
Spring Data JPA 查询方法命名要注意哪些边界情况
写 findByStatusAndDueDateBefore 看似没问题，但实际执行时若 dueDate 为 null，JPA 默认生成的 SQL 不会跳过该条件，而是查 due_date ——结果永远为空。这不是语法错，是语义陷阱。
更隐蔽的问题是大小写：MySQL 默认不区分大小写，但 PostgreSQL 区分，findByTitleContaining 在后者中可能查不到带大写字母的结果，除非显式加 IgnoreCase。
立即学习“Java免费学习笔记（深入）”；
- 涉及可空字段的查询，优先用
@Query+ 原生 SQL 或 Criteria API，控制WHERE条件动态拼接 - 模糊匹配统一用
findByTitleContainingIgnoreCase，避免数据库方言差异 - 分页查询务必传入
Pageable，别自己写LIMIT/OFFSET—— Spring Data 会自动适配 H2/MySQL/PostgreSQL 的分页语法
定时任务触发后如何安全更新任务状态并避免并发冲突
用 @Scheduled(fixedDelay = 30000) 扫描待执行任务，然后批量调用 taskRepository.saveAll(tasks)，看似简单，实则在多实例部署下大概率出现状态覆盖：两个节点同时查到同一条 status = 'PENDING' 的任务，都改成 'RUNNING'，最终只有一条生效，另一条被乐观锁拒绝或静默覆盖。
根本解法不是加分布式锁（太重），而是用原子更新 + 影响行数校验：
@Modifying
@Query("UPDATE Task t SET t.status = 'RUNNING', t.lastExecutedAt = CURRENT_TIMESTAMP " +
"WHERE t.status = 'PENDING' AND t.nextExecuteTime <= CURRENT_TIMESTAMP")
int markPendingTasksAsRunning();
执行后检查返回值是否 > 0，等于 0 表示没抢到任务，直接 return；大于 0 才继续后续处理逻辑。
- 禁止在事务内先
findAll()再逐条save()—— 这会放大并发窗口 - 更新状态字段必须包含版本号（
@Version）或使用上述原子 SQL，二者选一 - 如果任务执行耗时长，建议更新时顺带设置
executorId = ?（如机器 IP + PID），便于故障时定位谁卡住了
任务日志和执行结果该不该进同一个表
答案是否定的。把日志文本（可能几千字符）、堆栈、输入参数全塞进 task 主表，会导致主表膨胀、备份变慢、查询变卡。更麻烦的是，每次查任务列表（SELECT * FROM task）都会把大字段一起拖出来，哪怕前端只要标题和状态。
合理做法是垂直拆分：主表 task 只存核心字段（id, title, status, next_execute_time…），日志单独建 task_execution_log 表，用 task_id 关联，并加复合索引 (task_id, created_at) 支持按任务查历史执行记录。
- 日志表的
log_level字段建议用VARCHAR(10)存 'INFO'/'ERROR'，别用数字编码——可读性差且不易改 - 敏感参数（如密码、token）入库前必须脱敏，至少用
***替换中间部分 - 定期归档：用
DELETE FROM task_execution_log WHERE created_at 比用@Scheduled扫描对象再删更可靠
实际最难的不是写代码，是判断什么时候该用原生 SQL 而不是 Repository 方法，以及在「加锁」和「重试」之间选哪条路——这些没有银弹，得看你的 QPS、数据量、容错要求。
