Spring Boot任务跟踪系统毕设全攻略：从数据模型到答辩

不用怀疑，这个题目在Java毕设里属于性价比很高的那一档。

我前前后后参与指导过的毕业设计没有一百也有几十个，见过太多人选电商系统、博客系统、教务管理系统，结果一答辩就被评委问住：业务逻辑太简单，看不出工作量；或者技术栈堆得很花哨，但核心功能一戳就破。

“基于Spring Boot的软件开发项目任务跟踪系统”这个题，表面上听起来不如“智慧校园系统”那么唬人，但实际做下来，它覆盖了一个合格Java Web项目几乎所有的核心知识点：用户角色权限、任务状态流转、多表关联查询、统计报表、操作日志、消息通知。业务场景真实、复杂度适中、可扩展性强，而且你想往深了做，有足够的余地；想保底按期交付，也有清晰的裁剪空间。

这篇文章我就以这个题目为蓝本，把我认为最值得参考的设计思路、数据模型、核心逻辑、答辩准备和踩坑经验完整梳理一遍。无论你是刚定题还没动工，还是已经建了项目但心里没底，这份内容都能帮你少走不少弯路。

1. 这个毕设题目为什么值得选：从评委视角的利弊分析

选毕设题目这件事，很多人的第一反应是“哪个题看起来更高级”。但真正决定成绩的，是你能不能在有限时间内把一个系统做到逻辑自洽、功能完整、演示顺利。从这个角度看，任务跟踪系统远比那些追求“大而全”的题目聪明得多。

1.1 业务逻辑真实，但复杂度不失控

任务跟踪系统的业务场景来自软件公司在实际研发流程里的真实需求：一个项目拆成多个任务，任务分配给具体的人，每人的完成状态在团队内透明可见。这套逻辑天然具备几个特点：

• 角色边界清晰。管理员、项目经理、普通开发人员，各自能看什么、能操作什么，天然就是一个权限控制的示范案例。
• 数据关系明确。用户、项目、任务、评论、日志、统计，这些表之间的关系并不复杂，但又不是只有一张表的“玩具系统”。
• 演示场景直观。你不需要准备一堆虚构的电商订单来证明系统能用，现场演示一个任务从创建到分配、到状态变更、到统计报表的过程，评委一眼就能看懂。

相比动辄十几个模块的电商系统，任务跟踪系统把复杂度控制在了“忙得过来”的范围内。相比博客系统这类纯内容展示，它又多了业务状态机和多人协作的关键深度。

1.2 系统覆盖的知识点足以支撑毕业设计答辩

我记得有个评委老师私下聊过一段话：毕业设计答辩的时候，我不指望学生做出一个生产级别的商业系统，我只想确认三件事——你能不能把一个需求拆成功能模块？你能不能设计出合理的数据表结构？你能不能把自己写的代码讲清楚？

任务跟踪系统恰好能帮你把这个问题完整地回答一遍。它涉及映射表设计、枚举状态定义、复杂条件查询、统计聚合，以及前后端联调和部署配置。你甚至不需要额外引入Redis、MQ这些东西，用Spring Boot原生能力加一个MySQL就能交出质量很高的答卷。这个组合也是Spring Boot项目在招聘市场上最主流、最常被问到的技术栈组合之一。

提示：如果简历上想写“熟悉Spring Boot开发流程”以及“掌握MySQL基本设计与优化”，用这个项目作为支撑案例非常合适。答辩时被问到“做过什么项目”，你至少能围绕一个闭环讲清楚。

1.3 合适的题目选择范围与定题策略

任务跟踪这个方向，你在知网上也能搜到名字差不多的参考论文，但这里我不建议照着抄。毕设的核心价值不是论文写得多华丽，而是系统能跑起来、思路能讲明白。如果指导老师要求结合“敏捷开发”“协同办公”之类的概念，你可以把它写成“基于Spring Boot的敏捷开发任务协同跟踪平台”，本质不变，但立意更贴合软件工程的热点方向，这也是一部分学院老师比较在意的加分项。

2. 系统怎么拆：从需求到模块边界的完整规划

动工写代码之前，把模块拆清楚永远比把代码写得花哨重要。很多人一上来就建Controller、写Entity，结果做到一半发现数据表缺字段、返回格式不统一，返工率极高。我建议先花一个晚上把系统当成真实产品去拆解。

2.1 先把角色和权限边界画清楚

任务跟踪系统至少要支持三类角色，这是后台管理类系统最典型的权限模型：

• 管理员（Admin）：负责用户管理、项目管理、全局配置，可以查看所有项目和任务。
• 项目经理（Manager）：可以创建项目、创建任务、分配任务、调整任务状态、查看项目统计。
• 普通成员（Member）：可以查看自己被分配的任务、更新任务状态、发表评论。

这里有一个常见的设计误区：很多人在用户表里只放一个role字段，用0、1、2表示角色，然后每个请求都去查这个字符串做判断。对于毕设来说，这种设计够用，但如果能把角色做成一个独立的表，再引入用户-角色-菜单的基本分配逻辑，那么你答辩时讲权限控制的深度会完全不同，而且代码结构也更好维护。

2.2 功能模块怎么划分

按我习惯的拆分方式，系统可以分成六大模块，每个模块对应一组相对独立的页面和接口：

• 用户认证模块：登录、登出、当前用户信息获取、密码重置。
• 项目管理模块：项目的新增、编辑、归档、列表展示、项目成员维护。
• 任务管理模块：任务创建、编辑、详情、列表查询、分配、状态更新、删除（或归档）、任务附件上传。
• 评论与动态模块：针对某个任务的评论，以及任务状态变更时的系统提示。
• 统计看板模块：按项目维度统计任务总数、已完成数量、未完成数量；按成员维度统计每人名下任务分布。
• 系统管理模块：用户管理、角色管理、操作日志。

如果时间充足，加分项可以加一个消息通知功能：任务被分配或状态被修改时，给相关人员发送一条站内消息，或者通过WebSocket实时推送未读数量。这个功能不会增加太多的数据库复杂度，但演示效果很好，答辩老师会觉得系统在“协作”维度上有真实的设计考虑。

2.3 功能点清单：优先级排序是控制进度的关键

别想着把上面所有模块都做到极致，毕设真正决定成败的是“核心闭环是否完整”。我建议把功能点分成三个优先级：

关键经验：先把P0做完，确保能跑通全流程，再考虑加花活。我见过太多人一开始就死磕前端UI，拖拽看板做了两周，结果登录接口还没有，最后只好熬夜补后端，得不偿失。

3. 技术选型的底气：Spring Boot + MySQL 这套组合为什么稳

这套题目用Spring Boot配MySQL，不只是因为模板里这么写，而是它确实是最适合毕设场景的搭配。理解这套组合的底细，对你写文档、应付答辩都很有帮助。

3.1 为什么是Spring Boot而不是SSH或者纯Servlet

Spring Boot最大的价值是把Spring生态的配置复杂度吃掉了。你在application.yml里写几行配置，就能拥有一个内嵌Tomcat的Web应用，不用再手动配置一堆XML和外部服务器。对于毕设这种规模的项目，它让你把精力集中在业务代码而非环境搭建上，这对时间有限的毕业生来说太重要了。

另外，从就业角度讲，Spring Boot已经成了中小企业Java后端的事实标准，简历上写“熟练使用Spring Boot”比写“熟悉SSH框架”要讨喜得多。如果你学有余力，还可以在这套系统里顺手用上MyBatis-Plus作为ORM框架，而不是手写SQL和ResultSet映射，这会大大提升你的开发效率，同时也是目前国内企业最常用的开发方式。

3.2 为什么是MySQL而不是更轻量的数据库

团队协作系统本身就适合用关系型数据库来描述。任务、用户、项目之间的关系，翻译成外键和关联表非常自然。MySQL除了免费之外，最大的优势是生态成熟、社区资料多，遇到任何问题都能在网络上搜到成熟的解决方案。

你可能听人说过SQLite更轻、MongoDB更灵活，但说实话，在毕业设计这个语境下，用它们属于给自己添麻烦。MySQL 8.0以上的窗口函数、JSON字段、公共表表达式（CTE）这些特性足够你做出不错的统计和查询。举个很现实的好处：任务列表页需要按状态、负责人、优先级、日期范围组合筛选，这种场景写SQL语义非常明确，用MySQL处理再顺手不过。

3.3 版本搭配与JDK兼容性：容易踩的隐性坑

很多同学在做Spring Boot项目时，最头疼的不是代码逻辑，而是版本不兼容导致的环境问题。这里先给出一套我自己验证过比较稳妥的版本组合：

网上有很多版本的“最新版”教程，但最新的不一定是最稳的。技术选型上，毕设追求的是稳定复现，而不是尝鲜。如果你的电脑上已经装好了某个版本的JDK，不要轻易升级，让项目去适配你本地的环境，而不是反过来。

注意：Spring Boot 3.x和2.x在配置上有一个很大的区别，3.x使用Jakarta EE命名空间，包名从javax.*变成了jakarta.*，如果参考老代码复制粘贴，极易报包不存在的错误。如果没有特殊要求，建议直接选择Spring Boot 2.7.x，资料多、坑少。

4. 核心数据模型：任务表、项目表、用户表怎么设计才不返工

数据模型是整个系统最值得用心的地方。表设计得合理，后面写Mapper和Service会非常顺畅；设计得不好，写一个功能就要回头改一次表，时间全耗在无意义的重复劳动上。

4.1 用户表：别把账户信息和用户资料混在一起

很多人的第一版用户表会这样建：

code复制sys_user
- id
- username
- password
- nickname
- role
- create_time

这个设计够用，但如果项目需要扩展“负责人”“创建人”这些概念，最好再考虑一个更清晰的字段划分。我的建议是这张表里至少包含 id, username, password, real_name, email, phone, avatar, status, create_time，其中密码字段务必存BCrypt加密后的密文，不要明文存储。这个细节在答辩时如果被问到安全问题，会是一个很加分的回答。

4.2 项目表：维持轻量，只保存项目本身的信息

项目表不需要太复杂，建议核心字段这样定：

注意一点：项目成员关系不要直接塞进项目表，单独建一张project_member关联表，字段用project_id和user_id即可，这张表你可以用来做成员维度的统计，比在项目表里存一串逗号分隔的ID要规范得多。

4.3 任务表：这是整个系统的灵魂

任务表的字段设计决定了后续所有功能的实现方式，务必认真对待。下面是我认为比较合理的核心结构：

有几个地方要特别强调：

status为什么用TINYINT而不是VARCHAR？ 用数字存状态码便于数据库聚合统计和排序，也更节省空间。你可以在Java枚举里定义好常量值，保证代码里只出现语义化名称，而不是到处写魔法数字。

负责人为什么允许为空？ 因为现实中确实存在任务先创建、后指派的情况。如果这个字段设为NOT NULL，那么创建任务时就必须选人，业务流程就会僵硬。

deleted字段意味着什么？ 这是逻辑删除的关键，任务做了删除操作后，实际上是把deleted置为1，而不是物理删掉记录。这样做的好处是历史评论、历史统计不会因为删除而断链，这在项目开发里是一种很常见的工程实践。

4.4 任务评论表与日志表：协作跟踪的关键落点

既然系统名称里有“跟踪”两个字，那么任务的历史轨迹就不能忽略。我强烈建议建一张task_log表，每次任务状态发生变化、负责人被调整时，插入一条日志记录。这张表设计为：

code复制task_log
- id
- task_id
- operation_type   // 如：create, assign, status_change, comment
- operator_id      // 操作人ID
- content          // 操作描述，比如“状态从待办修改为进行中”
- create_time

评论区也类似：task_comment表保存用户针对一个任务的讨论内容。这个机制最大的好处是，你在任务详情页能展示出一条完整的时间线，用户登录后能看清任务从创建到当前状态的所有变化。这个时间线功能在演示时非常抓眼球，而且在答辩时可以清楚地讲出“跟踪”二字的业务含义。

5. 核心业务逻辑的落地：状态流转、权限控制、分页筛选、统计报表

数据模型准备好之后，核心业务逻辑的实现就是把设计落成代码的过程。这个阶段有几个关键点特别值得注意，提前想清楚了能省去大量返工时间。

5.1 任务状态流转：不要允许状态乱跳

一个任务的状态不能随意变化。比如任务已经完成了，就不能再退回到待办状态；一个已阻塞的任务，也不能直接跳到已完成。你需要定义清楚状态之间的合法转换路径，这道题在答辩时有一个专门的问法：你有没有考虑业务状态机？

我的实现方式是：用Java枚举定义TaskStatus，在updateStatus方法里做一步合法性校验。简单的方式是提前定义好一个允许转换的映射关系，比如：

java复制public enum TaskStatus {
    TODO(0, "待办"),
    IN_PROGRESS(1, "进行中"),
    COMPLETED(2, "已完成"),
    BLOCKED(3, "已阻塞");

    public static boolean canChange(int from, int to) {
        // 已完成的任务不允许再被修改
        if (from == COMPLETED.getCode()) {
            return false;
        }
        // 待办可以改为进行中、已阻塞或已完成
        if (from == TODO.getCode()) {
            return to == IN_PROGRESS.getCode() 
                || to == BLOCKED.getCode() 
                || to == COMPLETED.getCode();
        }
        // 进行中允许改为已完成或已阻塞
        if (from == IN_PROGRESS.getCode()) {
            return to == COMPLETED.getCode() || to == BLOCKED.getCode();
        }
        // 已阻塞可以改为待办或进行中
        if (from == BLOCKED.getCode()) {
            return to == TODO.getCode() || to == IN_PROGRESS.getCode();
        }
        return false;
    }
}

这个校验逻辑不只是在后端做，前端也要同步做判定，比如某个状态下的任务不显示“标记完成”按钮。双端校验的好处是，前端避免用户误点，后端防止接口被直接调用绕过限制，这是Web安全里一个很重要的思想。答辩时如果被问到“如何防止恶意请求”，你就能立刻用这个例子说明。

5.2 权限控制：用拦截器还是Spring Security

对于毕设项目，我个人的建议是使用HandlerInterceptor加自定义注解的方式做接口级别权限控制，而不是直接引入Spring Security。原因是Spring Security虽然功能强大，但配置项和过滤器链的复杂度容易让人陷进去。

先定义一个拦截器，在执行Controller方法前取出请求头里的Token，解析出当前登录用户，然后把用户信息存入ThreadLocal，后面的Service层直接通过UserContext.getCurrentUser()获取当前用户。对于管理员相关接口，用自定义注解@RequireRole("ADMIN")标注，拦截器里做判断即可。

这样做的好处是代码简洁、思路清晰，而且这个“Token解析+上下文存储”的流程在面试时也是高频考点，你说起来头头是道，完全能显示出对Web请求处理过程的理解。

5.3 登录流程与密码加密：一个必须处理的细节

登录流程不能只做“用户名密码对比成功就放行”。至少要做到：

• 密码使用BCrypt加密存储。Spring Security的BCryptPasswordEncoder或spring-security-crypto可以直接集成，不要用MD5加盐之类的落后方案。
• 登录成功后签发Token。可以用JWT（jjwt或java-jwt库），把用户ID、用户名、角色放进Token里。
• 前端把Token存到localStorage，请求时放在Authorization请求头，后端拦截器统一解析。

如果你不想引入JWT，也可以使用UUID随机会话号存入Redis，但这又多引入一个Redis依赖。对于毕设来说，JWT方案是最合理的选择：不增加服务端存储压力，代码量也小。

5.4 分页筛选与统计SQL：数据量上来了也能撑住

任务列表页基本都需要条件组合筛选，比如“只看我自己的任务”“只看某个项目的任务”“按优先级排序”。这里有一个重要的实践：不要把筛选逻辑散落在前端，而是通过后端统一接收查询条件。建议设计一个TaskQueryDTO，包含projectId、assigneeId、status、priority、keyword、pageNum、pageSize等字段，Mapper层用动态SQL拼接查询条件。

如果用MyBatis-Plus，可以用LambdaQueryWrapper来做条件构造。一个典型的查询是这样的：

java复制LambdaQueryWrapper<Task> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(StringUtils.hasText(query.getKeyword()), Task::getTitle, query.getKeyword())
       .eq(query.getProjectId() != null, Task::getProjectId, query.getProjectId())
       .eq(query.getStatus() != null, Task::getStatus, query.getStatus())
       .eq(query.getAssigneeId() != null, Task::getAssigneeId, query.getAssigneeId())
       .orderByAsc(Task::getPriority)
       .last("LIMIT " + (query.getPageNum() - 1) * query.getPageSize() + ", " + query.getPageSize());
Page<Task> page = taskMapper.selectPage(new Page<>(query.getPageNum(), query.getPageSize()), wrapper);

统计看板部分，则需要写聚合SQL。统计某个项目下按状态分组的任务数量，SQL大概是：

sql复制SELECT status, COUNT(*) AS task_count 
FROM task 
WHERE project_id = #{projectId} AND deleted = 0
GROUP BY status;

再加上按用户维度统计负责任务数量的SQL，就构成了看板的两个核心图表数据源。前端如果使用ECharts，稍微整理一下数据格式就能画出漂亮的饼图或柱状图，演示效果会很加分。

5.5 消息通知和站内信：这是拓展深度的好方向

消息通知可以做成一个独立的消息表，字段包括接收人、发送人、关联任务ID、消息内容、是否已读、创建时间。任务被分配或者状态变更时，除了写日志，再插入一条消息记录。前端在导航栏显示一个未读消息的小红点。如果想让演示效果更进一步，还可以用WebSocket实现新消息的实时推送，但这部分工作量会略大，属于有精力再做的高级扩展。

6. 数据库初始化与演示数据的准备：让答辩演示不尴尬的细节

很多毕设项目功能完全没问题，但演示效果一塌糊涂，问题往往出在数据库里空荡荡的，点开列表什么都没有。你想想，评委看到一张空表，怎么相信你的系统真的能用？演示数据的准备不是小事。

6.1 演示数据怎么造才像真的

不要随便填几条“测试1”“测试2”这样的数据。真实的任务跟踪系统里，应该有：三到四个用户、两到三个项目、每个项目下若干条任务，任务状态最好覆盖待办、进行中、已完成、已阻塞，评论里也留几条带有上下文的讨论。

这里分享一个小技巧：把演示数据的创建脚本写成一个独立的data-demo.sql，在项目README里写清楚如何导入。这样无论你换机器演示还是指导老师要测试环境，都能很方便地把数据恢复出来。制作演示数据时尽量把时间线拉长一点，比如一周内创建的项目和任务，日期分布要合理，不要全都是同一天。

6.2 初始化SQL脚本怎么组织

建议把所有建表语句放在sql/schema.sql中，演示数据放在sql/data-demo.sql中。项目里的application.yml中配置数据库连接时，可以直接设置spring.sql.init.mode=always并指定对应的SQL文件，让项目启动时自动初始化。或者你更喜欢手动执行也完全没问题，关键是确保任何人拿到的项目压缩包都能一键启动。

注意：如果使用Spring Boot自带的SQL初始化，要注意执行顺序。默认情况下，它先执行schema.sql再执行data.sql。如果你在Spring Boot 2.5之后使用spring.sql.init.encoding=UTF-8，防止中文演示数据乱码。

6.3 演示路线：设计一条“有故事”的单人操演流程

答辩时演示不要一个页面一个页面漫无目的地点，一定要有一条清晰的业务线。我这里给你一条可以借鉴的演示路线：

1. 用管理员账号登录，展示用户管理页面，说明不同角色的权限差异。
2. 进入项目管理页面，展示已有的3个项目。然后新建一个项目。
3. 进入新项目，创建一个任务，指派给某位开发人员。
4. 切换到那名开发人员的账号，进入任务列表，看到刚才被分配的任务。
5. 修改任务状态为“进行中”，并添加一条评论。
6. 切回管理员账号，查看任务详情的时间线，评论和状态变更日志完整展示。
7. 进入统计看板页面，展示按状态统计的图表。

这条路线只需要几分钟，但把系统最核心的价值“从分配、执行、反馈到汇总”完整串起来了。评委顺着这条线走下去，对你的系统印象会比零散点击强得多。

7. 文档、源码讲解与答辩：从会做到会讲，还要会卖

系统做出来只是第一步，能把自己做的东西清楚表达出来，才是毕业设计真正拿高分的关键。很多同学代码写得不错，一到答辩就支支吾吾，导致评分不理想。这部分的准备其实是可以提前练的。

7.1 论文和设计文档怎么组织才不空洞

毕设论文或设计文档，学校一般会给出模板，但结构上通常包含几个核心章节。这里比较重要的是不要抄教材目录，而是把你项目里真实做的事写进去：

• 绪论部分：先写软件开发团队中任务跟踪管理的背景，再写国内外常见的任务管理工具（比如Jira、Trello）的现状，接着引出自己要做什么。
• 需求分析部分：把角色、功能模块、业务流程用文字加图的方式描述清楚。任务状态机画一张图会非常直观。
• 系统设计部分：包含总体架构说明（前后端分离，Spring Boot提供API，Thymeleaf/Vue作为前端）、数据库设计（表结构、E-R图）、关键模块设计。
• 实现部分：对核心模块进行代码级别的描述，比如任务状态流转的校验逻辑怎么写的、权限拦截器的实现方式等。
• 测试部分：列出核心功能点的测试用例，包括预期结果和实际结果。不一定非要写自动化测试，但你至少要做一遍系统的功能冒烟测试。

关键心得：写文档的时候，脑海里要有一个读者画像——对方是一个懂技术但完全不了解你项目的老师。你写的每一段内容都要能让他不看代码就理解你做了什么。图比文字更直观，时序图、流程图、状态图都会是加分的表达方式。

7.2 源码讲解怎么准备才能不冷场

源码讲解是答辩最容易翻车的环节。有些同学一开始就把整个项目源码打开，一个文件一个文件往下面翻，讲得又长又没重点。我建议反过来，从“一段完整业务流程”讲起，而不是从“项目目录结构”讲起。

比如你可以这么讲：当用户在前端点击“创建任务”按钮后，请求到达TaskController.createTask()，Controller接收参数后调用TaskService.createTask()，Service里先做用户权限校验，然后补全创建人、初始状态等字段，接着调用TaskMapper.insert()写入数据库，最后写入一条操作日志。你就顺着这一条链路讲下来，把涉及到的每个类、每个注解带出来，比讲十页代码都有用。

评委很可能追问：“如果一个任务被删除了，但它下面的评论还存在，你怎么处理？”这个问题就能引出你的逻辑删除设计，以及查询时统一WHERE deleted = 0的做法。这种追问环节如果能对答如流，基本就稳了。

7.3 评委爱问的问题清单：提前练好嘴

结合我曾见过的毕业设计答辩现场，这类系统高频出现的追问方向大致如下：

• “为什么用Spring Boot而不用SSM？” 回答思路：Spring Boot内置Tomcat、自动配置、生态完善，开发效率高，本质还是Spring MVC。
• “任务列表查询慢时怎么优化？” 回答思路：优先分析SQL执行计划，看是否走了索引；任务表的project_id、status、assignee_id需要建合适的联合索引；分页查询用LIMIT，数据量大时可考虑按时间范围分片。
• “密码存的是什么形式？为什么？” 回答思路：BCryptHash，可以自动加盐，防止彩虹表攻击；数据库泄露后无法反推明文密码。
• “如果任务状态需要支持自定义流程，要怎么改？” 回答思路：把状态流转规则配置化，比如建一张状态流转表，或者使用Flowable/Activiti这类工作流引擎，但毕设场景下用枚举加校验就够了。
• “这个系统有什么安全方面的考虑？” 回答思路：密码加密、登录态校验、接口角色权限控制、防止SQL注入（预编译）、防止XSS（前端对输入做转义）。

这些问题并不算刁钻，但如果你从来没有提前思考过，临时很容易卡壳。建议你在答辩前把这些问题写在文档里，自己对着镜子或者找同学模拟两遍，练到能自然地把关键点说出来。

8. 这类毕设最容易翻车的几个地方：实测经验总结

最后这部分，我挑几个在实操中反复出现的坑展开说一下。这些坑不分学校、不分指导老师，几乎所有做类似题目的人都会遇到，提前知道能省一天甚至一周的时间。

8.1 环境配置：JDK版本、MySQL 8驱动和Maven下载

JDK版本问题。 如果你新开的工程用Spring Boot 3.x，而电脑上还在用JDK 8，启动时会直接报UnsupportedClassVersionError。反过来，用JDK 17跑Spring Boot 2.x也可能有问题。开发前先确认本机的java -version，再决定项目的版本方向。

MySQL驱动时区问题。 用MySQL 8.0之后，连接串里如果忘记配置serverTimezone=Asia/Shanghai，程序可能直接报The server time zone value '�й���׼ʱ��' is unrecognized，这个乱码提示看起来像编码错误，非常容易误判。正确做法是连接串写成：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/task_tracker?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

配置好之后，数据库字符集也尽量指定为utf8mb4，这样中文不会乱码，emoji也不会导致插入失败。

Maven依赖下载太慢。 不少同学在创建Spring Boot项目后，卡在依赖下载环节，一等就是半小时。解决办法是修改~/.m2/settings.xml，配置阿里云公共镜像。这个配置在答辩的机器上可能也需要，建议把settings.xml一起打包进你的资料目录里，做到环境可迁移。

8.2 时间管理：一条主线打通后再铺开

动手开发时，我强烈建议按以下顺序推进功能：先搞定登录认证，再搞定最简单的“新建项目+项目列表”，然后做“新建任务+分配状态”，等这条主线完全通了，再回头补统计、评论、消息通知等衍生功能。

有个很普遍的现象是，一个团队里有两个同学做类似题目，一个先把数据库设计好、把后端接口全部按Postman调试通过，再花轻松时间搞定前端；另一个做了几天前端页面，然后后端一接入就发现参数对不上、字段缺失，后面全部推倒重来。毕设的时间窗口就那么大，前者的方式值得借鉴。

8.3 答辩演示的辅助准备：录屏备份与离线预案

答辩现场的意外情况比想象中多，网络断开、演示机器没有预装JDK、数据库连不上、浏览器缓存带来的样式错乱，每一个都可能让演示瞬间尴尬。我建议在答辩前做三件事：

• 将系统完整运行一遍，用录屏软件把核心流程录下来，生成一个短视频文件。
• 把项目包、数据库脚本、环境配置说明放到同一个压缩包里，离线也能解压查看。
• 在演示机器上提前启动好项目并打开浏览器，确保一切就绪。

这些准备工作看起来简单，但在那种紧张的气氛下，作用非常明显。

8.4 关于“全bao”标签的一点提醒

市面上不少毕设服务打着“源码+文档+调试+代码讲解”的旗号，价格从几百到上千都有。我的建议是，不管你是否选择购买，最终交付和答辩环节必须建立在你自己对代码充分理解的基础上。这个系统的核心逻辑并不复杂，跟着本文的模块划分和关键逻辑走一遍，自己动手实现是完全可行的。如果你买了一套代码却完全看不懂，那么答辩现场老师追问任何一个细节，你都会陷入被动。

真正有价值的是你在开发过程中积累的那些经验和踩坑记录，这些内容属于你自己，谁也夺不走。

做这个系统，我觉得最有意思的地方在于，你把一个软件团队日常协作的抽象模型具象成了一个可运行的系统。做完之后，你不但拿到了毕业设计学分，还顺带把Spring Boot、MySQL、数据建模、权限控制这些在真实工作中每天都要用的核心技能过了一遍。这个项目的性价比，做过的同学应该都能体会到。