协作空间：我搭建的团队任务协作平台

从“这件事谁来做”，到“现在做到哪一步”，再到“完成后由谁确认”，团队协作中真正需要解决的，往往不只是记录任务，而是让责任、进度和沟通能够串联起来。

围绕这个目标，我搭建了一个 Web 端团队任务协作平台——协作空间。它将项目、成员、任务、评论、操作记录和通知整合在一起，希望让团队的工作过程更清晰，也更容易回顾。

项目地址：https://duck-live.top/collab/

从一个完整的协作过程出发

设计这个项目时，我没有只把它当成一个“任务增删改查”页面，而是先梳理了一条实际使用流程：

创建项目 → 添加成员 → 创建并分配任务 → 推进状态 → 评论沟通 → 提交验收 → 确认完成。

任务发生变化后，还应留下操作记录，并通知相关成员。这样，一个任务不仅有当前结果，也有可供追溯的过程。

围绕这条主线，平台逐步形成了工作台、项目列表、任务列表、任务看板、任务详情、成员管理和通知中心等页面。

平台可以做什么

用项目组织工作

每个项目有独立的成员关系和任务空间。用户可以查看自己参与的项目，进入项目后再处理具体任务、查看成员或回顾操作记录。

工作台则从个人角度汇总参与项目、未完成任务、逾期任务、待验收任务和未读通知，帮助用户先找到需要关注的事情。

用列表和看板查看任务

不同场景适合不同视角：

• 任务列表便于查看字段、筛选条件和分页结果。
• 任务看板按状态组织任务，更容易观察项目的整体推进情况。

任务可以记录标题、描述、优先级、负责人和截止时间，并支持评论、归档和恢复。进入任务详情后，可以把任务信息和讨论过程放在一起查看。

让“做完”与“确认完成”分开

平台设置了四个任务状态：

待处理 → 进行中 → 待验收 → 已完成。

状态流转由服务端校验，涉及“已完成”的确认与重新打开，需要项目管理员操作。

这个设计让“执行者认为已经完成”和“项目已经确认完成”有了明确区别，而不是由任何成员随意修改最终状态。

按项目分配权限

平台支持三种项目角色：

角色	主要职责
管理员	管理项目与成员、分配任务、验收任务
成员	在权限范围内创建、处理任务并参与讨论
访客	查看项目内容，保持只读

角色是按项目划分的。同一个用户可以在一个项目中担任管理员，在另一个项目中作为普通成员参与。

前端根据权限展示操作入口，后端则再次校验成员身份、任务归属和操作权限。权限控制不会仅依赖按钮是否可见。

留下记录，也及时提醒

任务更新、状态变更、成员调整等操作会产生相应的活动记录，方便回顾项目发生过什么变化。

与用户相关的任务指派、状态变化和评论等信息，则通过通知中心呈现。平台结合 WebSocket/STOMP 提醒与 HTTP 通知同步，让通知既有实时入口，也有持久化记录可以查询。

技术上是怎样实现的

前端采用 Vue 3、TypeScript、Vue Router、Pinia 和 Element Plus，使用 Vite 构建。

后端采用 Java 17、Spring Boot、MyBatis-Plus 和 MySQL，提供 RESTful API，并通过 WebSocket/STOMP 支持个人通知。

部署时，协作平台与我的个人博客保留独立目录、运行进程和数据库，通过 Nginx 在同一个域名下分流：

• /：个人博客。
• /collab/：团队任务协作平台。

这样的组织方式保留了两个项目各自的边界，也让它们可以分别维护和更新。

页面之外，更需要处理的问题

这个项目中，我花精力关注的不只是界面，还有多人操作时容易出现的细节。

避免旧页面覆盖新数据

两个人同时打开一个任务时，后提交的人可能仍拿着旧数据。

为此，任务更新携带版本号。服务端发现请求版本已经过时，就返回冲突，让用户重新查看最新内容，而不是直接覆盖其他人的修改。

对于成员移除与任务分配等涉及多张表的操作，还结合项目行锁和数据库事务，在修改前重新检查当前业务条件。

让业务变更和记录一起提交

如果任务已经修改成功，操作记录或通知却没有保存，后续追溯就会不完整。

因此，相关任务变更、活动记录和通知记录放在同一事务中处理；实时提醒则在事务提交后触发，避免先通知用户、随后数据库却回滚的情况。

这并不意味着实时消息能够在任何故障下绝不丢失，而是让持久化记录成为事实依据，再配合同步机制恢复通知。

防止异步响应“串到别的页面”

快速切换任务或账号时，先发出的请求可能更晚返回。如果直接使用它的结果，就可能把旧任务内容覆盖到新页面。

平台在相关请求与通知同步路径中结合请求序号、用户凭据和连接轮次判断结果是否仍然有效，并对部分编辑场景保存本地草稿，减少异常或冲突时重新输入的成本。

从本地运行到真正部署

项目部署到宝塔时，遇到了数据库名称与用户名不匹配、数据库登录认证失败、子路径资源访问以及浏览器登录状态排查等问题。

这些经历让我更明确地意识到：页面能在本地打开，只是项目交付的一部分。

配置是否正确加载、前端请求是否到达对应后端、数据库是否完成迁移、静态资源路径是否正确，以及日志显示的是不是本次启动，都需要逐层确认。

项目已有针对权限、版本冲突、事务回滚、通知同步和前端异步行为的测试与验证记录；目前定位仍是单机个人展示项目，尚未以生产级容量或多实例高可用作为完成标准。

后续还想继续完善什么

接下来，我希望继续完善账号管理、异常提示、通知降级与跨账号异步操作隔离，并补充更完整的线上多用户协作验证。

对我来说，这个项目的价值不仅是做出几个页面，而是把一个业务流程从需求、界面、接口和数据库，真正连接到部署与排错环节。

把协作过程，留在一处。 这是平台登录页的一句话，也是这个项目想持续做好的方向。