企业官网建设流程全解析

任务管理功能几乎是每个业务系统的“标配”，但说实话，大多数团队做出来的任务管理只是一个“任务登记本”：能新增、能改状态、能列表查询，仅此而已。业务方开始提需求时也确实只说了“记录一下就行”，可一旦系统真正用起来，问题立刻暴露——任务被谁处理了？当前卡在哪个环节？超时了为什么没人管？退回重做时状态怎么记？这时候再回头改流程，代价已经翻了好几倍。

这篇文章不打算写一个只能演示的 Demo，而是讲清楚一套任务管理流程从设计到落地的完整思路：状态机怎么设计、表结构怎么拆、核心代码怎么写、超时任务怎么处理、上线后有哪些坑。整套方案基于 Spring Boot 的常见技术栈实现，即使你用的是其他语言或框架，流程设计和表结构的部分也可以直接借鉴。读完你可以照着把一套可用的任务管理流程接入自己的项目。

1. 任务管理流程真正难在哪儿

很多人以为任务管理的难点在“任务的新增和编辑”，实际上后端写几个 CRUD 接口，前端做两个页面，确实很快就能跑起来。但一个系统做完之后被业务方评价为“不好用”，问题往往出在任务状态失控和流程规则缺失上。

1.1 状态失控：谁都可以改，谁也说不清

最典型的场景是：开发人员打开任务详情，看到“状态”字段是下拉框，待处理、处理中、已完成、已关闭随便选。看起来灵活，但业务上没法约束。一个已经“已完成”的任务被改回“待处理”，系统根本不知道中间发生了什么；一个“处理中”的任务被直接置成“已完成”，中间的耗时、负责人都没有记录。等到月底统计绩效或者复盘项目延期原因时，数据全是乱的。

真正的任务管理流程，状态不应该是自由修改的字段，而应该是受规则约束的状态机。每一步状态变化，必须满足前置条件，必须记录变更人、变更时间和变更原因。这不是为了限制用户，而是为了让任务流转过程可追溯。

1.2 超时无人处理：任务发出去就石沉大海

再常见的场景是：任务分派给某人之后，对方一直不处理，没有提醒、没有升级机制。业务人员只能线下催，催不动就找领导，最后问题又回到了“系统不好用”。

超时和升级机制是任务管理流程里最容易遗漏、也最影响使用体验的部分。一套合格的任务管理流程，需要能够定义任务的 SLA（服务等级协议），比如“普通任务 3 天内完成，紧急任务 24 小时内完成”，并且在任务超时前给出提醒，超时后自动升级给上级或重新分派。

1.3 三个关键判断

在动手设计之前，我有几个明确的判断，供你参考：

• 第一，任务管理流程的核心是状态机设计，不是页面设计。页面做得再漂亮，状态流转逻辑不清楚，系统依然是乱的。
• 第二，任务管理流程的本质是流程引擎的轻量实现。你不需要引入 Activiti 或 Flowable 这种重量级工作流引擎，大部分业务场景用一张状态表和一段状态机校验逻辑就能覆盖 90% 的需求。
• 第三，做好任务管理流程的关键，不是功能多，而是规则明确、动作可追溯、超时可感知。这三个点做到位，系统就已经超越了大多数“任务登记本”。

2. 任务管理流程的核心概念与状态设计

要写代码之前，先要把概念和状态定义清楚。这里有几个容易搞混的术语，先做区分。

2.1 三个容易混淆的概念

任务（Task）：指一件需要被完成的具体事情，比如“修复订单导出超时 Bug”“完成 4 月经营数据报表”。它是任务管理的主体对象。

任务状态（Task Status）：指任务当前处于生命周期中的哪个阶段，比如待处理、处理中、已完成。它是任务流转的判断依据。

任务动作（Task Action）：指对任务执行的某个操作，比如提交、受理、完成、退回、取消。动作触发状态变化。

如果打在比喻里：状态是任务当前“停在哪一站”，动作是任务“坐什么车去下一站”。设计流程时，思考顺序应该是先定义状态，再定义动作，最后把动作对应的状态变化画成一张表。

2.2 一套可复用的任务状态定义

不同业务场景下的任务状态名称可能不同，但通用模型可以归纳为以下几类：

这套状态定义的特点：

• 状态数量控制在 5 到 6 个，足够覆盖大多数业务场景。状态过多会加大维护成本，状态过少则缺少过程跟踪。
• “待验收”状态不是必须的，如果你是内部任务管理，成员完成任务后直接置为“已完成”也可以。但如果是外包协作、跨部门任务，验收环节建议保留。
• 每个状态都有一个明确的“负责人”，比如“待受理”这个状态的负责人是当前待分派的人或角色，“处理中”的负责人是受理人。负责人清晰之后，超时任务才能准确找到责任人。

2.3 状态流转规则

状态定义好之后，还需要画出“状态流转表”，这张表会直接指导后面的代码实现。以下是一份常见的流转配置：

设计这张表时，有几条经验：

• 不跳过中间状态。比如不允许“待受理”直接变成“已完成”，必须经过“处理中”。这样每一步都有记录。
• 退回必须填原因。退回动作如果不需要理由，业务上很容易被滥用，日志也失去了审计价值。
• 限制可操作人。不是任何角色都能对任意状态执行任意动作。如果系统没有完善的权限体系，至少要在代码逻辑里校验当前操作人是否在“可操作人范围内”。

2.4 小结论

任务管理流程的骨架是状态机。把状态和动作定义清楚，后面无论是写接口、做页面还是写定时任务，都会非常顺。这里真正值得花时间的不是写代码，而是和业务方把状态流转表确认清楚。如果业务方说“我们也不确定”，你可以先按上面这套最简模型上线，后续再扩展。

3. 任务管理流程整体架构与模块划分

确认完状态设计，接下来考虑系统架构。任务管理流程不是一个独立的复杂系统，但如果要在已有业务系统中新增这一块，建议按模块拆分，避免把所有逻辑堆在一个类里。

3.1 分层架构

推荐采用经典的四层结构：

关键点在于领域层的状态机逻辑要独立于应用层。如果状态机校验和业务编排混在一起，后续每加一个业务场景都容易改崩原有流程。

3.2 核心模块划分

根据功能职责，任务管理流程可以拆成以下模块：

1. 任务创建模块：负责创建任务，设置标题、描述、优先级、截止时间、处理人/角色。
2. 任务分派模块：负责将任务分配给具体的人，支持直接分派和按角色分派。
3. 任务处理模块：负责受理、完成、退回、转派等状态流转操作。
4. 任务验收模块：负责验收通过或驳回。
5. 任务查询模块：负责列表查询、详情查询、状态历史查询。
6. 任务调度模块：负责超时扫描、提醒通知、升级处理。
7. 任务审计模块：记录所有操作日志，便于追溯。

对于一个团队内部使用的任务管理流程，模块 1 到 5 是必须的，模块 6 强烈建议做，模块 7 第一次上线可以只记录日志表，不强制做分析页面。

3.3 一个容易犯的错误：把状态逻辑写在 Controller 或 Service 里

很多新手会这样写：Controller 里接收一个status字段，前端把状态直接传过来，后端只是做一个 update。这样做的直接后果就是状态字段变成了“随便填”的普通字段，前面说的状态失控问题根本没法避免。

正确做法是：前端只能传“动作”不能传“目标状态”。比如点击“受理”按钮，前端传的是action = "accept"，而不是status = "PROCESSING"。后端根据动作判断当前状态是否允许流转，如果允许，再由后端计算出目标状态并更新。这个设计是状态机落地的关键，后面代码部分会演示具体写法。

4. 环境准备与前置条件

为了确保这篇教程可以完整运行，环境准备部分说明如下。版本信息以你实际项目为准，本文重点演示通用思路。

4.1 技术栈

• Java 8 或以上
• Spring Boot 2.x 或 3.x
• MyBatis 或 Spring Data JPA（任选一种，本文以 MyBatis 为例）
• MySQL 5.7 或以上（也可以用 H2 内存数据库做本地演示）
• Maven 3.6 或以上

4.2 项目依赖

以 Maven 项目为例，核心依赖如下：

<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

如果你的项目使用的 Spring Boot 3.x，注意mybatis-spring-boot-starter的版本需要与 Spring Boot 3 适配，具体版本以官方说明为准。

4.3 配置示例

在src/main/resources/application.yml中配置数据源：

spring: datasource: url: jdbc:mysql://localhost:3306/task_flow?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.taskflow.entity configuration: map-underscore-to-camel-case: true

关键配置说明：

• map-underscore-to-camel-case: true可以自动将数据库字段task_name映射到 Java 属性taskName，避免手写 ResultMap。
• mapper-locations指定 XML 文件位置，如果你使用注解方式写 SQL，可以省略。
• 如果是本地演示，可以使用 H2 数据库，修改url和driver-class-name即可。

5. 任务管理流程核心代码实现

下面进入代码部分。这一节是整个文章的核心，重点讲清楚三个关键代码点：状态机校验逻辑、任务创建、状态流转。代码可以按文件位置直接复制进项目。

5.1 任务实体

文件路径：src/main/java/com/example/taskflow/entity/TaskInfo.java

package com.example.taskflow.entity; import lombok.Data; import java.time.LocalDateTime; @Data public class TaskInfo { private Long id; /** 任务标题 */ private String title; /** 任务描述 */ private String description; /** 优先级：LOW / MEDIUM / HIGH / URGENT */ private String priority; /** 当前状态：PENDING / PROCESSING / WAITING_ACCEPT / COMPLETED / CLOSED / CANCELED */ private String status; /** 创建人用户ID */ private Long creatorUserId; /** 处理人用户ID */ private Long assigneeUserId; /** 截止时间 */ private LocalDateTime deadline; /** 实际完成时间 */ private LocalDateTime finishedTime; /** 创建时间 */ private LocalDateTime createTime; /** 更新时间 */ private LocalDateTime updateTime; }

为了让状态定义和动作定义可以复用，建议把常量类单独建出来：

文件路径：src/main/java/com/example/taskflow/constant/TaskConstant.java

package com.example.taskflow.constant; public class TaskConstant { /** 任务状态 */ public static final String STATUS_PENDING = "PENDING"; // 待受理 public static final String STATUS_PROCESSING = "PROCESSING"; // 处理中 public static final String STATUS_WAITING_ACCEPT = "WAITING_ACCEPT"; // 待验收 public static final String STATUS_COMPLETED = "COMPLETED"; // 已完成 public static final String STATUS_CLOSED = "CLOSED"; // 已关闭 public static final String STATUS_CANCELED = "CANCELED"; // 已取消 /** 任务动作 */ public static final String ACTION_ACCEPT = "ACCEPT"; // 受理 public static final String ACTION_COMPLETE = "COMPLETE"; // 完成 public static final String ACTION_SUBMIT = "SUBMIT"; // 提交验收 public static final String ACTION_REJECT = "REJECT"; // 驳回 public static final String ACTION_PASS = "PASS"; // 验收通过 public static final String ACTION_RETURN = "RETURN"; // 退回 public static final String ACTION_TRANSFER = "TRANSFER"; // 转派 public static final String ACTION_CANCEL = "CANCEL"; // 取消 public static final String ACTION_CLOSE = "CLOSE"; // 关闭 }

5.2 状态机核心逻辑

这是任务管理流程最关键的部分。建议把状态流转规则封装到一个独立的类中，这个类不依赖 Spring 容器，纯 Java 实现，方便单元测试。

文件路径：src/main/java/com/example/taskflow/domain/TaskStateMachine.java

package com.example.taskflow.domain; import com.example.taskflow.constant.TaskConstant; import java.util.HashMap; import java.util.HashSet; import java.util.Map; import java.util.Set; public class TaskStateMachine { private static final Map<String, Map<String, String>> TRANSITIONS = new HashMap<>(); static { register(TaskConstant.STATUS_PENDING, TaskConstant.ACTION_ACCEPT, TaskConstant.STATUS_PROCESSING); register(TaskConstant.STATUS_PENDING, TaskConstant.ACTION_CANCEL, TaskConstant.STATUS_CANCELED); register(TaskConstant.STATUS_PROCESSING, TaskConstant.ACTION_COMPLETE, TaskConstant.STATUS_WAITING_ACCEPT); register(TaskConstant.STATUS_PROCESSING, TaskConstant.ACTION_RETURN, TaskConstant.STATUS_PENDING); register(TaskConstant.STATUS_PROCESSING, TaskConstant.ACTION_TRANSFER, TaskConstant.STATUS_PROCESSING); register(TaskConstant.STATUS_WAITING_ACCEPT, TaskConstant.ACTION_PASS, TaskConstant.STATUS_COMPLETED); register(TaskConstant.STATUS_WAITING_ACCEPT, TaskConstant.ACTION_REJECT, TaskConstant.STATUS_PROCESSING); register(TaskConstant.STATUS_COMPLETED, TaskConstant.ACTION_CLOSE, TaskConstant.STATUS_CLOSED); } private static void register(String from, String action, String to) { TRANSITIONS .computeIfAbsent(from, k -> new HashMap<>()) .put(action, to); } /** * 判断当前状态下是否可以执行指定动作 */ public static boolean canTransition(String currentStatus, String action) { if (currentStatus == null || action == null) { return false; } Map<String, String> actionMap = TRANSITIONS.get(currentStatus); return actionMap != null && actionMap.containsKey(action); } /** * 获取目标状态；如果不可流转，返回 null */ public static String getTargetStatus(String currentStatus, String action) { if (currentStatus == null || action == null) { return null; } Map<String, String> actionMap = TRANSITIONS.get(currentStatus); if (actionMap == null) { return null; } return actionMap.get(action); } /** * 获取某个状态可执行的全部动作 */ public static Set<String> getAvailableActions(String currentStatus) { Map<String, String> actionMap = TRANSITIONS.get(currentStatus); if (actionMap == null) { return new HashSet<>(); } return actionMap.keySet(); } }

这段代码的意义在于把“状态流转规则”集中管理。后续如果要新增一个状态或者调整流转关系，只要改这个类，再补充对应的单元测试即可，不用在业务代码里到处找 if-else。

5.3 任务创建服务

文件路径：src/main/java/com/example/taskflow/service/TaskService.java

package com.example.taskflow.service; import com.example.taskflow.constant.TaskConstant; import com.example.taskflow.entity.TaskInfo; import com.example.taskflow.mapper.TaskInfoMapper; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; import javax.annotation.Resource; import java.time.LocalDateTime; @Service public class TaskService { @Resource private TaskInfoMapper taskInfoMapper; @Transactional(rollbackFor = Exception.class) public Long createTask(TaskInfo task) { // 1. 基础参数校验 if (task.getTitle() == null || task.getTitle().trim().isEmpty()) { throw new IllegalArgumentException("任务标题不能为空"); } if (task.getDeadline() != null && task.getDeadline().isBefore(LocalDateTime.now())) { throw new IllegalArgumentException("截止时间不能早于当前时间"); } // 2. 初始化默认值 task.setStatus(TaskConstant.STATUS_PENDING); task.setCreateTime(LocalDateTime.now()); task.setUpdateTime(LocalDateTime.now()); // 3. 写入数据库 taskInfoMapper.insert(task); return task.getId(); } }

创建任务时有几个容易被忽略的点：

• 状态字段不允许前端传入，后端强制初始化为“待受理”。
• 截止时间不能早于当前时间，这一步在接口层校验一遍，在 Service 层再校验一遍，避免绕过接口层直接调 Service。
• 创建任务时要记录creatorUserId，后续验收、取消、重新打开操作都需要判断操作人是否为创建人。

5.4 状态流转操作

状态流转操作的写法与创建任务类似，但多一步校验：先查当前任务，再判断当前状态是否允许执行动作，最后更新状态。

@Transactional(rollbackFor = Exception.class) public void handleAction(Long taskId, String action, Long operatorUserId, String remark) { // 1. 查询任务 TaskInfo task = taskInfoMapper.selectById(taskId); if (task == null) { throw new IllegalArgumentException("任务不存在"); } // 2. 使用状态机校验 String currentStatus = task.getStatus(); if (!TaskStateMachine.canTransition(currentStatus, action)) { throw new IllegalStateException("当前任务状态不支持该操作，状态=" + currentStatus + "，动作=" + action); } // 3. 根据动作设置额外信息 if (TaskConstant.ACTION_ACCEPT.equals(action)) { task.setAssigneeUserId(operatorUserId); } if (TaskConstant.ACTION_COMPLETE.equals(action) || TaskConstant.ACTION_PASS.equals(action)) { task.setFinishedTime(LocalDateTime.now()); } // 4. 计算目标状态 String targetStatus = TaskStateMachine.getTargetStatus(currentStatus, action); task.setStatus(targetStatus); task.setUpdateTime(LocalDateTime.now()); // 5. 写操作日志 taskInfoMapper.updateStatus(task); // 6. 这里可以发送通知消息 // notifyService.sendTaskNotification(task, action, remark); }

这段代码是状态流转的核心写法。值得注意的两个细节：

• 先校验再更新：不能先 update 再判断，否则数据已经脏了。
• 操作日志单独记录：状态更新是必须做的，但操作日志同样重要。建议在同一个事务里插入一条task_status_log记录，保证状态变更和日志记录要么都成功、要么都失败。

5.5 定时任务：超时扫描与提醒

超时处理是任务管理流程里最体现工程完成度的功能。这里给出一个基于 Spring Scheduled 的轻量实现思路。

文件路径：src/main/java/com/example/taskflow/job/TaskTimeoutJob.java

package com.example.taskflow.job; import com.example.taskflow.constant.TaskConstant; import com.example.taskflow.entity.TaskInfo; import com.example.taskflow.mapper.TaskInfoMapper; import org.springframework.scheduling.annotation.Scheduled; import org.springframework.stereotype.Component; import javax.annotation.Resource; import java.time.LocalDateTime; import java.util.List; @Component public class TaskTimeoutJob { @Resource private TaskInfoMapper taskInfoMapper; /** * 每分钟扫描一次：找到所有已超时且状态还是待受理/处理中的任务 */ @Scheduled(cron = "0 * * * * ?") public void scanTimeoutTasks() { List<TaskInfo> timeoutTasks = taskInfoMapper.selectTimeoutTasks( TaskConstant.STATUS_PENDING + "," + TaskConstant.STATUS_PROCESSING, LocalDateTime.now()); for (TaskInfo task : timeoutTasks) { // 第一次超时给处理人发提醒 // 第二次超时升级给创建人或管理员 // 实际项目中建议通过消息队列异步发送，避免在定时任务中同步发送 System.out.println("任务超时提醒：taskId=" + task.getId() + ", title=" + task.getTitle() + ", assignee=" + task.getAssigneeUserId()); } } }

配合的 SQL 如下：

<select id="selectTimeoutTasks" resultType="com.example.taskflow.entity.TaskInfo"> SELECT * FROM task_info WHERE status IN <foreach collection="statusList" item="item" open="(" separator="," close=")"> #{item} </foreach> AND deadline IS NOT NULL AND deadline &lt; #{now} </select>

注意 XML 中小于号<的写法，直接写<会导致 XML 解析报错。

定时任务的实现方式很多，如果你的项目已经引入了 XXL-Job 或 ElasticJob，可以把scanTimeoutTasks迁移到分布式任务调度平台中。这里用 Spring Scheduled 是为了演示核心逻辑，生产环境中还要考虑任务只执行一次、避免多实例重复扫描等问题。

5.6 数据库设计相关说明

数据库表设计是整个流程的基石。这里用一个案例来说明。

假设你要为一家软件外包公司做任务管理系统。业务场景是：项目经理在系统中创建任务，安排给开发人员；开发人员受理后开始处理，完成后提交验收；项目经理验收通过，任务完成；如果验收不过，退回给开发人员重新处理。

按照这套流程，表中需要体现的信息包括：

• 任务基本属性：标题、描述、优先级、截止时间。
• 人员信息：创建人、处理人。
• 时间信息：创建时间、更新时间、完成时间。
• 状态信息：当前状态、状态历史。

任务主表可以这样设计：

CREATE TABLE `task_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `title` varchar(200) NOT NULL COMMENT '任务标题', `description` text COMMENT '任务描述', `priority` varchar(20) NOT NULL DEFAULT 'MEDIUM' COMMENT '优先级：LOW/MEDIUM/HIGH/URGENT', `status` varchar(20) NOT NULL DEFAULT 'PENDING' COMMENT '状态：PENDING/PROCESSING/WAITING_ACCEPT/COMPLETED/CLOSED/CANCELED', `creator_user_id` bigint(20) NOT NULL COMMENT '创建人用户ID', `assignee_user_id` bigint(20) DEFAULT NULL COMMENT '处理人用户ID', `deadline` datetime DEFAULT NULL COMMENT '截止时间', `finished_time` datetime DEFAULT NULL COMMENT '实际完成时间', `create_time` datetime NOT NULL COMMENT '创建时间', `update_time` datetime NOT NULL COMMENT '更新时间', PRIMARY KEY (`id`), KEY `idx_status_deadline` (`status`, `deadline`), KEY `idx_assignee_status` (`assignee_user_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='任务信息表';

状态历史表用于记录每一次状态变化：

CREATE TABLE `task_status_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `task_id` bigint(20) NOT NULL COMMENT '任务ID', `from_status` varchar(20) DEFAULT NULL COMMENT '原状态', `to_status` varchar(20) NOT NULL COMMENT '目标状态', `action` varchar(50) NOT NULL COMMENT '动作', `operator_user_id` bigint(20) NOT NULL COMMENT '操作人用户ID', `remark` varchar(500) DEFAULT NULL COMMENT '备注', `create_time` datetime NOT NULL COMMENT '操作时间', PRIMARY KEY (`id`), KEY `idx_task_id` (`task_id`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='任务状态流转日志表';

这里有一个重要的设计判断：状态字段在task_info表中保留一个“当前状态”字段，是为了查询和列表展示的方便；而task_status_log表记录的是“历史轨迹”。两者缺一不可。很多团队只做前者，不做后者，导致事后的追踪审计完全没有依据。

6. 完整示例：从创建到关闭的端到端验证

为了让你确认自己写的流程是对的，建议按下面的顺序跑一个完整流程。假设你已经成功启动项目，并且数据库表已经通过脚本初始化。

6.1 第一步：创建任务

使用 curl 调用接口：

curl -X POST "http://localhost:8080/api/tasks" \ -H "Content-Type: application/json" \ -d '{ "title": "修复订单导出超时问题", "description": "订单数量超过 10 万时，导出接口响应时间超过 30 秒", "priority": "HIGH", "creatorUserId": 1, "assigneeUserId": 2, "deadline": "2025-06-30 18:00:00" }'

预期响应：返回新任务的 ID，比如{"id": 1001}。

这个接口会校验“截止时间不能早于当前时间”，如果你测试时把deadline写成了过去的时间，接口会直接报错。

6.2 第二步：查询任务状态

curl -X GET "http://localhost:8080/api/tasks/1001"

预期输出中，status字段为"PENDING"。这是创建任务时由后端自动设置的初始状态，前端传进来的任何状态值都会被忽略。

6.3 第三步：受理任务

curl -X POST "http://localhost:8080/api/tasks/1001/action" \ -H "Content-Type: application/json" \ -d '{ "action": "ACCEPT", "operatorUserId": 2, "remark": "开始处理" }'

再次查询任务，status应变为"PROCESSING"，同时assigneeUserId被设置为操作人 ID。

6.4 第四步：尝试执行“非法动作”

curl -X POST "http://localhost:8080/api/tasks/1001/action" \ -H "Content-Type: application/json" \ -d '{ "action": "PASS", "operatorUserId": 2, "remark": "尝试跳过验收" }'

这个操作会被拒绝。因为状态机中“处理中（PROCESSING）”状态下没有定义PASS动作。接口会返回类似当前任务状态不支持该操作的错误。这一步能直接验证状态机规则是否生效。

6.5 第五步：完成 → 验收 → 关闭

# 完成处理，进入待验收 curl -X POST "http://localhost:8080/api/tasks/1001/action" \ -H "Content-Type: application/json" \ -d '{ "action": "COMPLETE", "operatorUserId": 2, "remark": "已修复并提交测试" }'

# 创建人验收通过 curl -X POST "http://localhost:8080/api/tasks/1001/action" \ -H "Content-Type: application/json" \ -d '{ "action": "PASS", "operatorUserId": 1, "remark": "验收通过" }'

# 管理员关闭任务 curl -X POST "http://localhost:8080/api/tasks/1001/action" \ -H "Content-Type: application/json" \ -d '{ "action": "CLOSE", "operatorUserId": 1, "remark": "归档关闭" }'

6.6 如何判断流程是否成功

整体跑完后，建议同时检查两类数据：

1. task_info表中的status是否最终变为CLOSED。
2. task_status_log表中是否有完整的 5 条记录：

如果日志表记录完整，说明状态机设计正确，事务回滚逻辑没有破坏审计记录。

6.7 验证失败时的排查入口

• 如果创建任务时报错“截止时间不能早于当前时间”，先检查你传入的 deadline 格式是否正确，以及系统当前时区是否配置为 Asia/Shanghai。
• 如果受理任务时报“任务不存在”，检查是否先完成了创建步骤，确认返回的 ID 在数据库中真实存在。
• 如果状态流转时报“当前任务状态不支持该操作”，先查询当前任务状态，再对照状态机配置表，确认该状态下确实允许此动作。

7. 常见问题与排查思路

8. 最佳实践与工程建议

任务管理流程本身逻辑不复杂，但涉及状态一致性、权限边界、定时任务、审计日志等多个方面，工程落地时建议遵循以下实践：

8.1 状态机必须是唯一修改状态的入口

所有状态变更都必须经过同一个服务方法，例如上面代码中的handleAction。不要在 Controller 里写task.setStatus(...)后直接updateById，这样会把状态机规则完全架空。代码审查时，重点审查是否有绕过状态机的写法。

8.2 幂等性设计

状态流转操作容易出现重复提交。比如用户点击两次“受理”按钮，如果没有幂等处理，第二次操作会被状态机拦截（因为状态已经是“处理中”），这是可以的。但更稳妥的做法是在接口层基于taskId + action做短时间内的重复提交校验，或者使用分布式锁保证同一任务同一时间只允许一个流转操作执行。

8.3 操作日志记录要细致

task_status_log表里的from_status字段非常重要。在更新状态前，先从数据库查出原始状态，记录到日志表，再更新当前状态。不要把from_status写死，也不要省略。

8.4 权限控制要提前做

为任务管理流程至少预留两个角色：普通成员和管理员。普通成员只能操作自己创建或分派给自己的任务，管理员可以查看和操作所有任务。如果流程中需要跨部门协作，建议增加“任务监督员”角色，负责查看进度但不直接处理任务。

8.5 配置与代码分离

超时阈值、提醒次数这些参数建议放到配置文件或配置中心，不要硬编码在代码里。否则业务方调整 SLA 时，每次都要改代码发版本。

task: sla: reminder-hours-before-deadline: 24 timeout-escalation-minutes: 30 notify: enabled: true

8.6 异常与回滚

创建任务、状态流转、日志记录这些操作必须在同一个事务中。万一状态更新成功但日志插入失败，整个事务回滚，保证数据一致性。

8.7 关于安全边界

任务管理流程涉及用户身份与权限校验。特别注意两点：

• 不要通过前端传入的operatorUserId直接作为操作人，应该从当前登录会话中获取用户身份。
• 勿在日志中打印完整敏感信息。如果任务描述中包含业务敏感信息，建议数据库字段加密存储，日志只记录任务 ID 和状态变化。

9. 总结与后续学习方向

这篇文章的核心结论只有一句话：任务管理流程不是“增删改查”，而是一套受状态机约束的生命周期管理。从待受理、处理中、待验收到已完成、已关闭，每一步都必须明确动作、操作人和前置条件。同时，超时扫描、操作日志、权限校验是让这套流程真正可用的三个辅助能力。

如果你想基于本文的流程继续深入，建议按以下方向扩展：

• 将状态机规则改为配置化。当前代码中状态机是写死的 Java 代码，如果业务复杂，可以考虑将状态流转表放入数据库，实现动态配置。
• 引入消息通知机制。任务被分派、被退回、超时即将发生时，都需要通过站内信、短信、邮件或企业微信等方式通知相关人员。建议使用消息队列异步发送，不要把通知逻辑写在主流程事务中。
• 引入分布式任务调度。如果系统是多实例部署，定时扫描任务需要加分布式锁，或者直接使用 XXL-Job 一类调度平台。
• 设计任务看板。任务列表之外，看板视图对业务方非常有用。按状态分组展示任务卡片，拖拽卡片改变状态，本质上调用的还是本文中的handleAction接口。
• 补充任务统计报表。按状态、按人员、按时效统计任务完成率、平均处理时长，这些数据是后续流程优化的依据。

最后提醒一点，如果系统里已经存在多个状态字段（比如订单状态、审批状态），不要各自孤立实现，建议将这套状态机设计抽象为一个通用组件，避免每个模块都重复实现一份“if-else 状态判断”。这个抽象过程本身也值得用一篇文章来展开。