Spring Boot+微信小程序打造高校师生工作室任务管理系统：状态机与权限设计全解析

看到 springboot + 微信小程序 + 高校师生工作室任务管理系统这个组合，很多人第一反应是“又一个毕业设计题目”。但我的判断恰恰相反：如果把这一行题目翻译成需求，它描述的是一种非常真实的协作失控场景——工作室群消息刷屏、任务发不下去、任务完成后没有任何沉淀、月底一算账谁都说不清自己干了什么。这是我在帮几个实验室、创新团队做内部工具时反复遇到的问题，所以这篇文章我会完全按照“要交付一个能白天答辩、晚上能真跑起来”的系统来拆。

这篇内容适合三类人：正在做类似选题的本科生/研究生、刚接手实验室管理想搞一套轻量工具的学生助理、以及想快速了解“Spring Boot 后端 + 微信小程序前端”完整落地链路的后端初学者。我会把它当作一个真实交付项目来讲，不会只贴一堆框架概念。核心要讲清楚几个关键点：任务状态机怎么设计才不会被各种边界情况打穿、为什么“认领任务”这种操作要用条件更新而不是先查再改、小程序端登录态和权限校验怎么配合后端，以及哪些地方是可以拿去吹亮点、哪些地方其实是给自己挖坑的功能。

1. 这个系统要解决的，不是“做个待办清单”这么简单

1.1 高校师生工作室的协作痛点到底在哪

先说一个我观察到的典型场景：一个工作室通常有负责人、指导老师、若干不同年级的学生。负责人发任务通常靠微信群，说一句“谁有空把下周汇报 PPT 做了”，然后群里安静十分钟，最后只能私聊点人。任务做到一半没有公开进度，验收时缺少标准，甚至做完之后连记录都找不到。

这种场景下，单纯做一个“每个人维护自己待办”的应用根本没意义，因为核心问题不是个人效率，而是团队的“任务可见性”和“责任闭环”。老师想知道任务分给了谁，学生想知道哪些任务可以认领、当前进展到哪一步，负责人需要的是“能追踪、能验收、能留痕”。所以这个系统真正的核心，不是界面多好看，而是把任务从创建、认领、执行、提交、验收到归档这一整条链路管住，每个人在任何时间点都能回答“现在这个任务卡在谁手里”。

1.2 角色划分与权限矩阵要第一时间想清楚

很多类似的毕设项目，代码写到一半才发现权限到处打补丁。原因就是一开始没把角色关系列成一张清晰的表。高校师生工作室里的角色，我建议不要设计得太复杂，四类足够覆盖绝大多数情况：

注意，负责人和老师之间的权限要有一定重叠，但又不完全一样。负责人侧重“项目管理”，老师侧重“过程指导与最终把关”。这样在做后端接口时，拦截器只需要判断“角色是否满足某个操作所需角色集合”即可，不需要在 controller 里写一堆 if else。

1.3 功能模块怎么划分才不会变成“大杂烩”

我看到过太多课程设计和毕业设计的问题：菜单一大排，什么公告、签到、题库、商城全塞进去，实际上彼此没有业务闭环。导师一问“你系统的核心流程是什么”，答不上来。

这个项目我建议只保留一条主线，再加两个辅助模块。主线是“项目—任务—认领—提交—验收”。辅助模块一个是“消息通知”，用户被指派任务、任务被打回、任务即将到期时要有站内消息；另一个是“数据看板”，用于展示工作室每个成员的任务完成情况，方便月度总结和评优参考。有了主线闭环，答辩时你能清晰讲出业务流转；有辅助模块，论文的工作量和新意也能体现出来。先把这几块做扎实，远比堆十个半成品菜单有价值。

2. 技术选型与整体架构：别为“看起来很高级”买单

2.1 后端为什么选 Spring Boot，版本怎么锁

Spring Boot 是目前写这种管理系统最稳妥的选择，没有之一。生态成熟、招人认可度高、出问题能搜到的资料最多。它自带的自动配置和 starter 机制，让数据库访问、Web 接口、参数校验、事务管理这些常规能力开箱即用。

但有个热搜词我特别想提醒：springboot 版本太高。很多人新建项目时默认选了最新的 Spring Boot 3.x，结果写代码时发现 javax 变成了 jakarta，很多网上教程和老依赖全都对不上，白白浪费大量时间。如果你不是对 Spring Boot 3 的新特性有明确需求，我建议直接锁 Spring Boot 2.7.18，JDK 用 8 或 11，资料最丰富、依赖最稳。如果学校硬性要求 3.x，那就要清楚 javax.servlet 换 jakarta.servlet、Spring Security 6 配置变化这些差异点，提前做好心理准备。

持久层我用的是 MyBatis-Plus。理由很直接：单表 CRUD 不需要手写 SQL，内置分页插件，条件构造器写起来很顺手；如果后面要写复杂统计 SQL，又能随时回到 XML 里手写，进退都有余地。JPA/Hibernate 也不是不行，但对大多数习惯 SQL 思维的学生来说，MyBatis-Plus 排查问题更直观。

2.2 前端用原生微信小程序还是 uni-app

这里我先表明态度：如果目标只是交付一个“微信小程序端”，我推荐用原生小程序开发，而不是一上来就引入 uni-app。原生小程序的页面结构就是 wxml + wxss + js + json，没有额外框架的学习成本，调用微信 API 时不需要经过一层封装，背锅路径短。更重要的是，答辩现场演示时，原生代码和微信开发者工具的结合最顺畅，不会出现“hbuilder 运行小程序报错半天打不开”的尴尬。

如果已经有 Vue 基础，又希望以后能编译到 H5 或其他平台，选 uni-app 也行。但一定要想清楚：这套系统本身没有多端需求，引入跨端框架带来的工程复杂度可能大于收益。系统前端规划四个主页面就够了：首页（任务看板与快捷操作）、任务列表页（任务池 + 我的任务分 Tab）、消息页、我的页面（个人信息与角色切换入口）。

2.3 部署架构与 Docker 化

部署是容易被忽略、但答辩时很加分的环节。单体架构下最轻量的方案是：一台云服务器，MySQL 和 Spring Boot 应用分别用 Docker 容器运行，小程序端请求通过 Nginx 反向代理转发到后端服务。这样做的好处是环境一致，换一台服务器也能快速重建。

一个简单的 docker-compose.yml 可以这样做：

yaml复制version: "3.8"
services:
  mysql:
    image: mysql:8.0
    container_name: task-mysql
    environment:
      MYSQL_ROOT_PASSWORD: root123456
      MYSQL_DATABASE: studio_task
      TZ: Asia/Shanghai
    volumes:
      - ./mysql-data:/var/lib/mysql
    ports:
      - "3306:3306"
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

  backend:
    image: openjdk:8-jdk-alpine
    container_name: task-backend
    depends_on:
      - mysql
    volumes:
      - ./app.jar:/app.jar
    ports:
      - "8080:8080"
    command: java -jar /app.jar --spring.profiles.active=prod

需要特别说明的是，微信小程序正式上线要求所有请求域名必须是 HTTPS 且完成 ICP 备案，开发者工具里可以临时勾选“不校验合法域名”来联调，但上线前一定要申请域名并配置 SSL 证书。这个点看似是运维问题，实际上很多人在最后提审时才被发现，往往要耽误一两周，项目排期必须提前预留。

3. 数据库设计与任务状态机建模：核心中的核心

3.1 核心表结构：六张表足够撑起整个项目

我见过有人为这种系统设计了三十多张表，最后大多数表里就几条测试数据。做内部管理系统，核心表控制在六张左右是最舒服的：用户表、项目表、任务表、任务日志表、消息表、附件表。下面给出关键的建表片段，字段以能支撑业务闭环为准。

sql复制CREATE TABLE `sys_user` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `username` varchar(64) DEFAULT NULL,
  `password` varchar(256) DEFAULT NULL,
  `real_name` varchar(32) NOT NULL,
  `role` tinyint NOT NULL DEFAULT 3 COMMENT '1管理员 2负责人 3导师 4学生',
  `openid` varchar(64) DEFAULT NULL COMMENT '微信openid',
  `avatar` varchar(512) DEFAULT NULL,
  `status` tinyint NOT NULL DEFAULT 1 COMMENT '1正常 0禁用',
  `create_time` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_openid` (`openid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

任务表是重头戏，状态字段设计直接决定后续逻辑复杂度：

sql复制CREATE TABLE `task` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `project_id` bigint DEFAULT NULL,
  `title` varchar(200) NOT NULL,
  `content` text,
  `publisher_id` bigint NOT NULL COMMENT '发布人',
  `assignee_id` bigint DEFAULT NULL COMMENT '当前执行人',
  `auditor_id` bigint DEFAULT NULL COMMENT '验收人',
  `priority` tinyint DEFAULT 2 COMMENT '1低 2中 3高',
  `status` tinyint NOT NULL DEFAULT 0 COMMENT '0待认领 1进行中 2已提交验收 3已完成 4已驳回',
  `deadline` datetime DEFAULT NULL,
  `version` int NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
  `create_time` datetime NOT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='任务表';

其余四张表分别是：project 存项目信息，task_log 存任务状态变更日志，message 存站内通知，file 存上传附件。注意要把 create_time、update_time 这类审计字段从一开始就加上，后面做数据看板时你会感谢自己当时的这个决定。

3.2 状态机怎么设计才不会越走越乱

任务状态是整个系统的灵魂。我设计的流转路径是：待认领 -> 进行中 -> 已提交验收 -> 已完成，任何进行中或已提交验收的任务都可能被驳回到进行中。更关键的是，要提前定义清楚“谁在什么状态可以做什么操作”，这就是状态机的迁移矩阵：

这张矩阵表写清楚之后，后端每个修改状态的接口就变成了一次“当前状态 + 目标操作 + 当前角色”的组合校验。一定不要写成前端点按钮直接就改数据库，因为接口是可以被绕过直接调的。状态校验逻辑建议封装成一个独立方法，比如 checkStatusTransition(currentStatus, targetStatus, operatorRole)，所有状态流转都走同一套校验，代码会干净很多。

3.3 为什么任务日志表能救你于水火

任务日志表最常见的用途是给数据看板提供素材，但它真正的价值在于：当用户之间出现争议——“我明明提交了，你怎么说我没交”——时，日志是最客观的证据。每次任务状态变化都插入一条日志，记录操作人、操作类型、备注信息。

在实现上，最简单的方式是复用切面或事务事件监听器。不过对这种体量的项目，我会选择直接在 service 层的方法里同步写日志，代码直观、误用成本低，也不用担心事务嵌套的问题。毕竟任务管理系统最怕的就是“状态变了但没人说得清是谁变的”，有日志兜底，很多扯皮问题都能快速定位。

4. 后端接口与关键业务逻辑：把每一条规则落到实处

4.1 统一响应结构与登录鉴权链路

后端接口我不会每个都返回裸数据，而是定义一个统一的 Result<T> 结构，包含 code、message、data 三个字段。这样小程序端封装 request 时只需要判断 code 是否为 200，不用每次处理异常结构。网关层、拦截器、全局异常处理器、参数校验器，这四个基础组件要在一开始搭好。

登录链路是微信小程序最关键的基建。小程序端通过 wx.login 拿到临时 code，后端拿这个 code 调微信的 code2Session 接口换取 openid。注意 secret 绝对不能暴露在小程序代码里，必须放在后端配置中。拿到 openid 后查用户表，如果用户存在就直接签发 JWT，如果不存在则进入注册流程，让用户补全姓名、学号、角色等信息。

实现起来大概是这个逻辑：

java复制@PostMapping("/login")
public Result<String> login(@RequestBody LoginDTO dto) {
    // 1. 后端用 code 请求微信接口，拿 openid
    String openid = wechatService.code2Session(dto.getCode());
    // 2. 查询用户
    User user = userService.getByOpenid(openid);
    if (user == null) {
        // 3. 不存在则返回需要注册的标记
        return Result.error(1001, "用户不存在，请先完善资料", openid);
    }
    // 4. 存在则签发 token
    String token = JwtUtil.createToken(user.getId(), user.getRole());
    return Result.ok(token);
}

这里有个细节：JWT 签发时不要只塞一个 userId，要把 role 也放进去。虽然角色可能会调整，但因为本系统的角色很少变化，这样后续做接口鉴权时，不需要每次从数据库里重新查用户再查角色，直接在拦截器里解析 token 就能拿到角色信息，性能更好，代码也更简洁。

4.2 任务认领的并发问题：条件更新是标准答案

系统里最容易出现并发问题的场景是“多个学生同时抢同一个待认领任务”。如果代码写成先查询任务状态，判断是待认领，然后再 update，两个请求同时读到的都是待认领，就会导致同一个人任务被两个人认领成功。

解决思路其实一句话：把判断和更新合并成一条 SQL，利用数据库行锁保证互斥。MyBatis-Plus 的条件构造器可以实现：

java复制boolean success = taskMapper.update(null, new LambdaUpdateWrapper<Task>()
        .set(Task::getAssigneeId, currentUserId)
        .set(Task::getStatus, 1)
        .eq(Task::getId, taskId)
        .eq(Task::getStatus, 0)
) == 1;

这条 SQL 翻译成人话就是：“只有任务还在待认领状态时，我才把它改成进行中，并把我自己设成执行人”。数据库层面会锁住这一行，后到的请求因为状态已经不是 0，更新影响行数为 0，就可以据此返回“任务已被认领”。整个过程不需要显式写锁，也不容易出现死锁，是非常推荐的做法。

4.3 提交验收、驳回与自动到期处理

提交验收入口同样要带状态条件，执行人只能把“进行中”的任务改成“已提交验收”，代码思路和认领一模一样。验收人通过时把状态改为“已完成”，驳回时不仅要改状态，还要填驳回原因。驳回原因建议单独存在任务日志表里，不要覆盖任务正文 content，因为你以后可能要用 UI 把“历史驳回记录”展示出来。

到期提醒可以用 Spring 自带的 @Scheduled 定时任务，每分钟扫描一次数据库中 deadline 在接下来 24 小时内且状态还是“进行中”的任务，然后给执行人和发布人生成站内消息。对于工作室这种几十人规模、任务总量几千条的数据量，一条带索引的 SQL 扫描完全没有压力，根本不必为了这点量去引入 Redis 延迟队列。

java复制@Component
public class TaskRemindJob {

    @Scheduled(cron = "0 0/30 * * * ?")
    public void remindDeadlineTasks() {
        // 查询未来24小时到期且未完成任务
        List<Task> tasks = taskMapper.selectList(new LambdaQueryWrapper<Task>()
                .in(Task::getStatus, 0, 1)
                .le(Task::getDeadline, DateUtil.offsetHour(new Date(), 24)));
        for (Task task : tasks) {
            messageService.sendRemind(task);
        }
    }
}

实际部署时，记得在 Spring Boot 启动类或专门的配置类上加 @EnableScheduling。这个定时任务以后还能扩展成“工作室周报自动生成”，是论文里一个很自然的演进点。

5. 微信小程序端：从登录到任务流的细节实现

5.1 全局 request 封装与登录态过期处理

如果在小程序每个页面都直接调 wx.request，那后面改域名、加 token、统一处理 401 时会想哭。建议在一开始就封装一个 request.js，把基础 URL、请求头、错误处理统一收敛起来。核心代码很短，但收益很大：

javascript复制const request = (url, method = 'GET', data = {}) => {
  return new Promise((resolve, reject) => {
    wx.request({
      url: getApp().globalData.baseUrl + url,
      method,
      data,
      header: {
        'Authorization': 'Bearer ' + wx.getStorageSync('token')
      },
      success: (res) => {
        if (res.data.code === 200) {
          resolve(res.data.data);
        } else if (res.data.code === 401) {
          // token 失效，跳转到登录页
          wx.removeStorageSync('token');
          wx.navigateTo({ url: '/pages/login/login' });
        } else {
          wx.showToast({ title: res.data.message, icon: 'none' });
          reject(res.data);
        }
      },
      fail: (err) => {
        // 网络异常时统一提示
        wx.showToast({ title: '网络连接失败', icon: 'none' });
        reject(err);
      }
    });
  });
};

这里要强调的是，401 的跳转逻辑必须做防重复处理。否则当一个页面同时并行发三个请求，三个都返回 401，就会连跳三次登录页，体验非常糟糕。简单做法是加一个“是否正在跳转”的标记位。

5.2 任务列表的分页、状态标签与下拉刷新

任务列表页建议分成三个 tab：任务池、我发布的、我执行的。任务池展示待认领任务，点击可查看详情并认领；我执行的任务要突出状态和时间；我发布的任务则要提供“撤回/催办”等操作入口。

分页是小程序端很容易忽略但必须做的。不要一次性查出几百条数据塞给前端，而是用 pageNum 加 pageSize 的方式，触底时自动加载下一页。后端返回结构建议统一成 { records, total, current, size }，小程序端用 onReachBottom 触发加载。

任务卡片的展示有个细节：状态字段最好由后端转成前端能直接显示的文本和颜色标识，比如 statusText: "进行中"，而不是让前端拿着 0、1、2、3、4 去自己翻译。别觉得这是小题大做，时间一长前后端人员一换，你会体会到这种“后端多回传一个字段”的做法有多么省心。

5.3 消息中心与未读红点

消息中心的价值容易被低估，但它恰恰是这个系统提升“好用感”的关键。当一个学生被指派了任务，或者提交的验收被打回时，如果没有消息提醒，用户可能永远不打开 App。实现上不需要引入 WebSocket，因为工作室场景不需要毫秒级推送，用户下拉消息页或者每次启动小程序时拉取未读消息就足够。

数据库消息表里加一个 is_read 字段，每次查询未读数就是一个 count 操作。在小程序首页或“我的”页面右上角显示红点，点击进入消息列表后，再把该用户的全部消息标记已读。这个功能实现成本低，但导师演示时一般都会点赞，因为“闭环 + 提醒”正是任务管理系统的价值所在。

6. 常见的设计难点与功能取舍：不是所有热点都要追

6.1 Flowable 工作流引擎到底要不要引入

最近很多人在 springboot 项目里聊 flowable，甚至热搜里都出现了“springboot 使用 flowable”和“flowable 整合 springboot 实战”。我的态度很明确：如果任务是简单的“发布—认领—提交—验收”，不要引入 Workflow 引擎，自己维护状态机完全是绰绰有余的，而且代码一目了然，调试也容易。

什么情况下值得引入 Flowable？当你的表结构出现明显多级审批需求，比如任务要经过“学生提交 -> 组长初审 -> 老师终审 -> 归档”四步，而且审批节点可能动态变化时，Flowable 这类流程引擎才能体现出优势。但引入它会带来新的复杂度：流程部署、流程实例、任务节点表、历史表等十几张表，还要学习 BPMN 画流程文件，对学生团队来说学习成本非常高。

我的建议是，如果论文需要一个“体现系统可扩展性”的亮点，可以在论文里写“自定义状态机满足当前需求，未来可按需引入 Flowable 工作流引擎支撑多级审批”，一句话带出即可。代码层面优先保证主线跑通，不要在答辩前一周临时引入一个之前没弄过的引擎。

6.2 消息实时推送用什么方案，要不要上 WebSocket

微信小程序里可以做两种消息：一种是站内消息，只在用户打开小程序时拉取；另一种是微信官方订阅消息，每次发送需要用户点击授权一次，使用限制很多，不太适合做频繁的任务提醒。站内消息对“师生工作室”这种低频协作场景已经完全够用，我用得非常顺手。

如果希望在用户不打开小程序时也有提醒效果，可以了解微信订阅消息。设计思路是：任务创建时，调用 requestSubscribeMessage 让执行人授权一次“任务提醒”模板，后端拿到授权结果后，在任务到期前通过订阅消息推送。但这个方案需要小程序有对应类目并审核通过，且每次授权只能发送一条消息，限制比较多。我建议把它作为论文的“可扩展方向”而非核心功能，避免陷入微信平台类目审核的泥潭。

6.3 需要数据看板时，怎么设计统计接口

数据看板是很多论文会比较重视的加分模块，因为可以贴出“可视化图表”，说明系统具备数据辅助决策能力。看板的数据来源不要在前端循环算，后端要用 SQL 一次算好。统计需求通常是：按成员统计任务完成数、按状态统计任务分布、本周新增任务趋势。

一个典型的成员工作量统计接口：

sql复制SELECT
  u.real_name,
  COUNT(t.id) AS total_task,
  SUM(CASE WHEN t.status = 3 THEN 1 ELSE 0 END) AS finished_task
FROM sys_user u
LEFT JOIN task t ON t.assignee_id = u.id
WHERE u.role = 4 AND t.create_time >= ?
GROUP BY u.id, u.real_name
ORDER BY total_task DESC

小程序端图表展示可以用 ec-canvas 这个 ECharts 小程序组件，也可以直接用简单的 CSS 柱状图、进度条。考虑到 Canvas 在低端 Android 机上的渲染表现，我倾向于在首页先用“进度条 + 数字”展示成员完成率，再在数据页用图表展示更复杂的统计结果。这样既好看又不会过度渲染。

6.4 文件上传是刚需，但要控制成本

工作室任务中经常要交文档、图片、压缩包。最常见的实现是把文件传到服务器本地磁盘，然后在数据库 file 表记录相对路径。上传接口要做三件事：限制文件大小、限制扩展名、用 UUID 重命名后存储。为什么用 UUID？因为学生提交的文件名经常是“新建文档(2).docx”，直接保存会出现覆盖或中文乱码问题。

本地存储时还要注意 Spring Boot 的静态资源映射。如果你把文件存到了 /data/upload 目录，而应用在 /app 目录下启动，直接访问 /upload/xxx.jpg 是找不到的，需要配置一个资源映射。用 WebMvcConfigurer 即可：

java复制@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
    registry.addResourceHandler("/upload/**")
            .addResourceHandler("file:/data/upload/");
}

这几个细节代码量都不大，但在真实交付中很能体现工程素养，面试官或评委问起来也有话可说。

7. 开发调试期容易踩的坑：每一条都是真金白银换来的

7.1 Spring Boot 版本太高导致的连锁反应

这个问题出现频率非常高，绝对值得单独列一个小节。用 Spring Boot 3.x 的同学，在引入旧版 MyBatis-Plus、旧版 Druid、旧版 knife4j 时经常遇到自动配置失效、类找不到的问题。因为从 Spring Boot 3 开始，官方把 javax.* 命名空间整体迁移到了 jakarta.*，大量老版本依赖是在 javax 下编译的，直接引入就会跑不起来。

一句话经验：在没有特别理由的情况下，选择 Spring Boot 2.7.18 作为基线版本。它既能享受 Spring Boot 2.x 时代最成熟的生态，也处于长期的维护周期内，教程和资料都能对你的代码从入门到上线全程负责。如果你的课程或老师要求必须上最新版，那遇到问题排查时，先看依赖是否已经兼容 jakarta，而不是去改业务代码，这个方向能省大量时间。

7.2 小程序开发者工具联调时的三个“不可抗力”

第一个是开发者工具默认会校验 HTTPS 域名。开发阶段，在“详情 -> 本地设置”里勾选“不校验合法域名”就能访问 http://127.0.0.1:8080。第二个是模拟器里 wx.login 生成的 code 与真机并不完全一样，有些能力必须真机预览才能看到真实效果，所以不要只依赖模拟器调试。第三个是工具本身偶尔会抽风，表现为代码保存后模拟器没反应或提示各种“不是开发者/端口被占用”的异常，常见处理是关闭所有微信开发者工具实例，重新打开，或者在命令行里执行 taskkill /f /im wechatdevtools.exe 后重试，比你检查半天代码有效得多。

本地开发时后端地址千万别写 https://...，要用 http://127.0.0.1:8080。如果你在手机上用真机预览，那 127.0.0.1 指向的是手机自己，后端肯定连不上，这时候要填电脑的局域网 IP。这个坑我见过太多次了，以为是后端代码出错，结果只是地址写错。

7.3 LocalDateTime 序列化与前后端字段不一致

后端 LocalDateTime 默认序列化出来是一串数组或复杂字符串，小程序端 JSON.parse 后看着很奇怪。解决方式是在 application.yml 里统一格式化时间：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

同时，前端展示“几天前”、“刚刚”这类相对时间时，不要依赖后端格式化好的字符串，而是在前端拿到 createTime 后自己计算，这样体验更自然，数据分发也更灵活。

另一个高频问题：前端提交的数据用驼峰命名如 assigneeId，后端 Java 实体也习惯用驼峰，但数据库列名是下划线 assignee_id，如果开启了 MyBatis-Plus 的驼峰映射，通常没问题。但注意某些复杂 SQL 手写时要手动加 AS assigneeId 别名，否则返回的 Map 中 key 会是 assignee_id，前端取不到值，报错还会非常隐蔽。

7.4 测试环境与调试建议

后端接口不要等全部写完再测，每完成一个模块就用 Apifox 或 Postman 把该模块的接口过一遍，尤其是权限拦截器是否生效。我习惯在每个接口开发完成后写一次“正向流程 + 反向越权”两个用例：正向流程确认功能可用，反向越权确认普通学生调验收接口会返回 403。任务改动状态的接口尤其要测边界，比如已完成的任务再提交一次，应该返回“当前状态不允许该操作”。

最后再分享一个我自己的小习惯：面对这类系统，先别急着写代码，打开数据库设计工具或者一张白纸，把任务状态机和权限矩阵画出来。画到每个角色每个状态都有明确的下一步操作时，后端代码的工作其实已经完成了一半。后面写的每一行代码都能在状态图上找到对应，出问题时也能迅速判断是状态判断不完整还是数据错误。这套方法不只能用在毕业设计上，任何带审批、带流程的业务系统都适用。