产品团队协作工具从0到1：线程化沟通与实时推送实现

做产品的人应该都有这种感觉：需求、评审、排期、上线反馈，散落在 IM 群聊、邮件、文档和会议纪要里。每次对齐都要翻聊天记录，一个话题聊完就没了上下文，新同学加入团队之后，根本不知道之前为什么做这个决定。如果有一个工具，能把“沟通”本身组织成可追踪、可检索、可回放的线程，同时把关键决策结构化沉淀下来，产品团队的协作效率会明显提升。

这篇文章不绑定任何具体商业产品，而是围绕“产品团队高效沟通”这个主题，拆解一款 Show HN 风格协作工具从 0 到 1 的技术实现路径。内容会覆盖场景痛点、系统架构、数据模型、后端接口、WebSocket 实时推送、前端交互，以及与飞书、钉钉、企业微信等现有工具链的集成思路。适合对全栈协作类应用感兴趣的开发者，也可以直接作为内部团队工具 MVP 的落地蓝本。

1. 背景与核心概念

1.1 产品团队沟通的现状与痛点

产品团队的日常工作可以简单概括为：接收需求、讨论方案、评审排期、推进开发、验收上线、收集反馈。这套流程看起来清晰，实际执行时却经常被“沟通成本”拖垮。

最常见的现象是信息碎片化。一个需求的讨论可能分布在多个群聊里，早上的方案评审在一个群，下午的设计确认在另一个群，晚上又有人在文档评论区提出问题。想把整个决策链路串起来，往往需要同时打开好几个页面，效率很低。

第二个痛点是上下文丢失。IM 群聊天然是时间线式的，聊天记录会被大量消息冲刷。一个需求讨论到一半，隔了两天再回来，前因后果已经模糊。如果团队里有成员变动，后续接管的人要从零开始补背景，问题更明显。

第三个痛点是沟通结果没有沉淀。很多团队讨论完就完了，最终结论散落在聊天记录里。到了月底复盘，想统计这个月讨论了多少需求、哪些被采纳、哪些被驳回，没有任何结构化数据可以支撑。

这类问题恰好是“产品团队沟通工具”想解决的：把沟通变成线程化、结构化、可检索的协作流。每个主题有自己的标题、状态、成员和完整时间线；@ 提及代替“在群里喊一嗓子”；订阅和通知让相关人员及时感知进展，又不会被无关消息打扰。

1.2 什么是“高效且愉悦”的团队沟通工具

回到标题里的两个关键词：enjoyable 和 efficient。

efficient 比较容易理解。一个高效的团队沟通工具，应该具备几个基本能力：

• 线程化讨论，每个主题独立成线，不会被其他消息冲散。
• 结构化字段，比如需求状态、负责人、截止时间，方便筛选和统计。
• 强大的检索能力，历史讨论可以快速被重新找到。
• 合理的通知机制，只通知需要知道的人，而不是全员轰炸。

enjoyable 则更难实现。它强调使用体验上的轻快感：消息发送要即时，界面交互要流畅，操作路径要短。用户愿意主动使用，工具才能产生价值。很多内部工具失败，不是功能不够，而是用起来太笨重，最后大家还是回到 IM 群里聊天。

从技术角度看，enjoyable 意味着实时通信的体验要好，前端交互的反馈要快，数据加载要流畅。这些要求会直接影响架构设计和技术选型。

1.3 技术目标与本文范围

本文要实现的是一套可运行的最小闭环系统，核心流程包括：

• 用户加入团队空间。
• 在空间内创建主题线程，也叫 thread。
• 团队成员在线程下发布消息、@ 提及同事。
• 被提及的人收到站内通知。
• 前端通过 WebSocket 实时收到新消息推送。
• 关键事件通过 Webhook 推到已有 IM 工具群。

这套闭环覆盖了产品团队日常沟通 80% 的场景。实现完成后，你可以继续扩展富文本编辑、附件上传、全文检索、移动端适配等能力。

2. 系统设计：架构与功能拆分

2.1 核心功能模块

在设计阶段，先把系统拆成几个清晰的模块，避免后续开发时职责混乱。

人员与权限模块负责用户的注册、登录、团队空间管理，以及成员角色控制。产品沟通工具通常分成 owner、admin、member 三种角色，owner 管理团队空间，admin 可以管理成员，member 正常参与讨论。

线程模块是沟通的核心载体。一个线程对应一个主题，比如“登录页改版需求沟通”。线程需要包含标题、详情描述、创建人、当前状态、创建时间和更新时间。状态可以设计为 open、in_progress、resolved、closed，对应需求的讨论中、推进中、已解决和已关闭。

消息模块负责线程下的内容交流。每条消息记录发送人、正文、@ 提及的用户列表和发送时间。为了保留讨论的上下文，消息按时间递增排列，形成完整的时间线。

通知模块在 @ 提及或订阅事件发生时，给相关用户生成站内通知。通知模块还需要具备简单免打扰能力，比如用户可以对某个线程设置静默。

实时通信模块负责把新消息即时推送到前端。这里使用 WebSocket。用户进入某个线程时，前端建立连接并订阅该线程；后端收到新消息后，把消息推送给所有订阅该线程的在线用户。

集成模块是产品团队工具能否真正落地非常关键的一环。团队不会轻易放弃正在使用的飞书、钉钉或企业微信。工具需要把关键讨论事件通过 Webhook 推送到已有群聊，形成“外部通知 + 内部沉淀”的配合模式。

2.2 总体技术架构

整个系统采用前后端分离架构。

前端负责页面渲染和用户交互，通过 REST API 获取数据，通过 WebSocket 接收实时消息。传统多页应用配合 jQuery 也能实现，但推荐使用 React 或 Vue 这类组件化框架，因为聊天流式页面有大量状态变化，组件化开发维护成本更低。

后端负责业务逻辑、权限校验、数据持久化和消息推送。可以选择 Spring Boot、Go、Node.js 或 Python，核心思路一致。本文示例使用 Spring Boot，因为它在国内后端团队中使用率很高，生态成熟，资料丰富。

数据存储使用关系型数据库，PostgreSQL 或 MySQL 都可以。表格关系比较明确，适合用 JPA 或 MyBatis 这类 ORM 来操作。实时在线状态和短期热点数据可以放在 Redis 里，但本文最小闭环不需要引入 Redis，避免过早复杂化。

2.3 技术选型说明

版本需要根据项目实际情况调整，本文示例以常见环境为主，重点演示配置思路。下面是推荐的选型组合：

如果团队后端是 Node.js，可以用 Express 或 NestJS 配合ws库实现同样的能力。如果团队更熟悉 Go，可以用 Gin 配合 gorilla/websocket。核心设计思路是通用的。

2.4 项目结构规划

后端项目建议按职责分包，下面是一个参考结构：

com.example.collab ├── CollabApplication.java ├── config │ └── WebSocketConfig.java ├── controller │ ├── AuthController.java │ ├── ThreadController.java │ └── MessageController.java ├── service │ ├── ThreadService.java │ ├── MessageService.java │ └── NotificationService.java ├── repository │ ├── TeamRepository.java │ ├── TeamMemberRepository.java │ ├── ThreadRepository.java │ └── MessageRepository.java ├── entity │ ├── User.java │ ├── Team.java │ ├── TeamMember.java │ ├── Thread.java │ ├── Message.java │ └── Notification.java └── dto ├── CreateThreadRequest.java └── SendMessageRequest.java

前端项目如果使用 React，建议按页面和组件拆分。

src ├── api │ ├── thread.js │ └── message.js ├── components │ ├── ThreadList.jsx │ ├── ThreadDetail.jsx │ └── MessageInput.jsx ├── pages │ └── TeamBoard.jsx └── websocket └── client.js

项目结构不是一成不变的，但建议从第一天起就保持边界清晰，后面加功能会轻松很多。

3. 数据库设计与核心数据模型

3.1 实体关系梳理

核心实体包括用户、团队空间、团队空间成员、主题线程、消息、订阅和通知。

用户和团队空间是多对多关系，通过 team_members 中间表关联。一个用户可以加入多个团队空间，一个团队空间有多个用户。

线程属于团队空间，创建者是一个用户。消息属于线程，发送者是一个用户。通知属于接收用户，关联到线程和触发消息。订阅表示用户关注了某个线程。

这张关系模型和典型论坛系统非常接近，区别在于产品团队沟通工具更强调线程状态流转和成员订阅关系。

3.2 核心表 DDL

下面是基于 PostgreSQL 的建表语句，MySQL 需要把 BIGSERIAL 换成 BIGINT AUTO_INCREMENT，把 JSONB 换成 JSON。

-- 用户表 CREATE TABLE users ( id BIGSERIAL PRIMARY KEY, name VARCHAR(64) NOT NULL, email VARCHAR(128) NOT NULL UNIQUE, avatar_url TEXT, created_at TIMESTAMP NOT NULL DEFAULT NOW() ); -- 团队空间表 CREATE TABLE teams ( id BIGSERIAL PRIMARY KEY, name VARCHAR(128) NOT NULL, description TEXT, owner_id BIGINT NOT NULL REFERENCES users(id), created_at TIMESTAMP NOT NULL DEFAULT NOW() ); -- 团队成员关系表 CREATE TABLE team_members ( id BIGSERIAL PRIMARY KEY, team_id BIGINT NOT NULL REFERENCES teams(id), user_id BIGINT NOT NULL REFERENCES users(id), role VARCHAR(16) NOT NULL DEFAULT 'member', joined_at TIMESTAMP NOT NULL DEFAULT NOW(), UNIQUE (team_id, user_id) ); -- 主题线程表 CREATE TABLE threads ( id BIGSERIAL PRIMARY KEY, team_id BIGINT NOT NULL REFERENCES teams(id), title VARCHAR(256) NOT NULL, content TEXT NOT NULL, creator_id BIGINT NOT NULL REFERENCES users(id), status VARCHAR(16) NOT NULL DEFAULT 'open', created_at TIMESTAMP NOT NULL DEFAULT NOW(), updated_at TIMESTAMP NOT NULL DEFAULT NOW() ); -- 消息表 CREATE TABLE messages ( id BIGSERIAL PRIMARY KEY, thread_id BIGINT NOT NULL REFERENCES threads(id), sender_id BIGINT NOT NULL REFERENCES users(id), content TEXT NOT NULL, mention_user_ids JSONB DEFAULT '[]', created_at TIMESTAMP NOT NULL DEFAULT NOW() ); -- 线程订阅表 CREATE TABLE thread_subscriptions ( id BIGSERIAL PRIMARY KEY, thread_id BIGINT NOT NULL REFERENCES threads(id), user_id BIGINT NOT NULL REFERENCES users(id), muted BOOLEAN NOT NULL DEFAULT FALSE, created_at TIMESTAMP NOT NULL DEFAULT NOW(), UNIQUE (thread_id, user_id) ); -- 通知表 CREATE TABLE notifications ( id BIGSERIAL PRIMARY KEY, user_id BIGINT NOT NULL REFERENCES users(id), thread_id BIGINT NOT NULL REFERENCES threads(id), message_id BIGINT REFERENCES messages(id), is_read BOOLEAN NOT NULL DEFAULT FALSE, created_at TIMESTAMP NOT NULL DEFAULT NOW() );

注意 messages 表的 mention_user_ids 使用了 JSONB 类型，用于保存 @ 提及的用户 ID 数组。这样设计的好处是不需要额外建关联表，查询一条消息时可以直接拿到被提及人列表。

3.3 索引与分页注意点

高频查询是“按团队查线程列表”和“按线程查消息列表”。建议在 threads 表的 team_id 和 created_at 上建联合索引，在 messages 表的 thread_id 和 created_at 上建联合索引。

CREATE INDEX idx_threads_team_created ON threads(team_id, created_at DESC); CREATE INDEX idx_messages_thread_created ON messages(thread_id, created_at); CREATE INDEX idx_notifications_user_read ON notifications(user_id, is_read);

分页时不要使用过大的 OFFSET，数据量增长后性能会下降。更好的方式是基于游标分页，使用WHERE id < ? ORDER BY id DESC LIMIT 20，这样能利用主键索引，性能稳定。

4. 后端接口与实时通信实现

4.1 REST API 设计

最小闭环系统主要提供以下接口：

在示例代码中，用户身份可以通过请求头X-User-Id传递，简化登录逻辑。真实项目中建议使用 JWT 或 Session，并且配合 Spring Security 做统一认证。

4.2 创建主题线程的实现

先创建一个简单的请求 DTO。

// 文件路径：src/main/java/com/example/collab/dto/CreateThreadRequest.java public class CreateThreadRequest { private String title; private String content; public String getTitle() { return title; } public void setTitle(String title) { this.title = title; } public String getContent() { return content; } public void setContent(String content) { this.content = content; } }

接着创建线程实体类。

// 文件路径：src/main/java/com/example/collab/entity/Thread.java @Entity @Table(name = "threads") public class Thread { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(nullable = false) private Long teamId; @Column(nullable = false) private String title; @Column(nullable = false, columnDefinition = "TEXT") private String content; @Column(nullable = false) private Long creatorId; @Column(nullable = false) private String status = "open"; @Column(nullable = false) private LocalDateTime createdAt = LocalDateTime.now(); @Column(nullable = false) private LocalDateTime updatedAt = LocalDateTime.now(); // getter 和 setter 省略 }

创建线程的业务逻辑放在 Service 层，核心是先校验成员关系，再保存线程数据。

// 文件路径：src/main/java/com/example/collab/service/ThreadService.java @Service public class ThreadService { private final ThreadRepository threadRepository; private final TeamMemberRepository teamMemberRepository; public ThreadService(ThreadRepository threadRepository, TeamMemberRepository teamMemberRepository) { this.threadRepository = threadRepository; this.teamMemberRepository = teamMemberRepository; } @Transactional public Thread createThread(Long teamId, Long userId, CreateThreadRequest request) { if (!teamMemberRepository.existsByTeamIdAndUserId(teamId, userId)) { throw new AccessDeniedException("当前用户不是该团队成员，无法创建讨论"); } Thread thread = new Thread(); thread.setTeamId(teamId); thread.setTitle(request.getTitle()); thread.setContent(request.getContent()); thread.setCreatorId(userId); thread.setStatus("open"); return threadRepository.save(thread); } }

这里的成员校验很重要。如果缺少这层校验，任何登录用户都可以往任意团队空间创建线程，这在产品团队工具中是严重越权行为。

Controller 层负责接收 HTTP 请求，并把用户身份传入 Service。

// 文件路径：src/main/java/com/example/collab/controller/ThreadController.java @RestController @RequestMapping("/api/teams/{teamId}/threads") public class ThreadController { private final ThreadService threadService; public ThreadController(ThreadService threadService) { this.threadService = threadService; } @PostMapping public Thread createThread(@PathVariable Long teamId, @RequestHeader("X-User-Id") Long userId, @RequestBody CreateThreadRequest request) { return threadService.createThread(teamId, userId, request); } }

4.3 发送消息与 @ 提及通知

发送消息是整个系统的核心操作。除了保存消息本身，还需要解析 @ 提及的用户，并生成站内通知。这个步骤必须放在同一个事务中，否则可能出现“消息保存成功但通知丢失”的数据不一致问题。

// 文件路径：src/main/java/com/example/collab/service/MessageService.java @Service public class MessageService { private final MessageRepository messageRepository; private final ThreadRepository threadRepository; private final NotificationRepository notificationRepository; public MessageService(MessageRepository messageRepository, ThreadRepository threadRepository, NotificationRepository notificationRepository) { this.messageRepository = messageRepository; this.threadRepository = threadRepository; this.notificationRepository = notificationRepository; } @Transactional public Message sendMessage(Long threadId, Long senderId, SendMessageRequest request) { Thread thread = threadRepository.findById(threadId) .orElseThrow(() -> new IllegalArgumentException("线程不存在")); Message message = new Message(); message.setThreadId(threadId); message.setSenderId(senderId); message.setContent(request.getContent()); message.setMentionUserIds(request.getMentionUserIds()); message = messageRepository.save(message); if (request.getMentionUserIds() != null) { for (Long targetUserId : request.getMentionUserIds()) { if (targetUserId.equals(senderId)) { continue; } Notification notification = new Notification(); notification.setUserId(targetUserId); notification.setThreadId(threadId); notification.setMessageId(message.getId()); notificationRepository.save(notification); } } return message; } }

一个小细节是跳过自己 @ 自己的情况。实际产品中，如果用户 @ 了自己，通常也不会希望收到一条通知。

发送消息后，如果希望前端实时看到，还需要把新消息推送到 WebSocket 订阅端。这个能力在下一节实现。

4.4 WebSocket 实时推送

Spring Boot 集成 WebSocket 非常方便。先引入依赖，注意版本由 Spring Boot 父工程统一管理。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-websocket</artifactId> </dependency>

然后编写 WebSocket 配置类，注册处理器。

// 文件路径：src/main/java/com/example/collab/config/WebSocketConfig.java @Configuration @EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { private final ChatWebSocketHandler chatWebSocketHandler; public WebSocketConfig(ChatWebSocketHandler chatWebSocketHandler) { this.chatWebSocketHandler = chatWebSocketHandler; } @Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(chatWebSocketHandler, "/ws") .setAllowedOrigins("*"); } }

接着实现一个简单的 TextWebSocketHandler。生产环境下需要按用户身份和线程维度管理会话，这里先演示连接管理和消息广播。

// 文件路径：src/main/java/com/example/collab/config/ChatWebSocketHandler.java @Component public class ChatWebSocketHandler extends TextWebSocketHandler { private static final Map<String, WebSocketSession> SESSIONS = new ConcurrentHashMap<>(); @Override public void afterConnectionEstablished(WebSocketSession session) throws Exception { SESSIONS.put(session.getId(), session); } @Override protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception { for (WebSocketSession s : SESSIONS.values()) { if (s.isOpen()) { s.sendMessage(message); } } } @Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) { SESSIONS.remove(session.getId()); } }

真正的产品实现需要把“广播”改成“按线程推送”。更合理的做法是维护一个threadId -> Set<Session>的映射，前端连接后先发送订阅指令，后端把会话加入对应线程的会话集合；发送新消息时，只遍历该线程下的会话。

当前示例先跑通最小闭环，再逐步完善。

4.5 前端接入实时消息

前端建立 WebSocket 连接，并在连接成功后订阅当前正在查看的线程。

// 文件路径：src/websocket/client.js const token = localStorage.getItem('token'); const ws = new WebSocket(`wss://your-domain.com/ws?token=${token}`); ws.onopen = function () { console.log('WebSocket 连接已建立'); ws.send(JSON.stringify({ type: 'subscribe', threadId: 1001 })); }; ws.onmessage = function (event) { const data = JSON.parse(event.data); if (data.type === 'NEW_MESSAGE') { appendMessageToTimeline(data.message); } }; ws.onclose = function () { console.log('连接关闭，准备重连'); setTimeout(() => connectWebSocket(), 3000); };

在生产环境中，需要注意几点：

• WebSocket 地址要使用 WSS 协议，保证消息传输加密。
• token 不要放在 URL 上，否则可能出现在日志里，可以考虑在连接成功后发送认证消息。
• 需要实现心跳检测，避免网络空闲时连接被中间设备断开。
• 前端要处理断线重连和消息补偿，重连后拉取最近消息，防止丢消息。

5. 与现有工具链集成

5.1 为什么必须做集成

产品团队沟通工具很难完全替代飞书、钉钉、企业微信这类 IM 工具。团队仍然会在 IM 里同步日常事务，如果新工具与 IM 完全隔离，用户就容易忘记打开它，最终导致工具被弃用。

解决办法是把工具嵌入到现有工作流中。当有人在系统里创建了重要线程，或者有消息 @ 到了某个同事，系统通过 Webhook 把摘要推送到团队 IM 群。用户可以继续在 IM 里看到通知，点击链接回到工具里参与讨论。

需要强调的是，具体调用哪个开放平台的接口，需要以对应平台的官方文档为准。不同平台的 Webhook 地址、签名规则和消息格式都不一样，集成时要注意区分。

5.2 通用 Webhook 推送

这里给出一个通用的 Webhook 推送思路。假设团队使用的 IM 平台支持“自定义机器人”能力，通常只需要向一个 Webhook URL 发送 POST 请求，即可把消息推送到群里。

public void pushToChatWebhook(String webhookUrl, String title, String content) { RestTemplate restTemplate = new RestTemplate(); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); Map<String, Object> body = new HashMap<>(); body.put("title", title); body.put("content", content); HttpEntity<Map<String, Object>> request = new HttpEntity<>(body, headers); restTemplate.postForEntity(webhookUrl, request, String.class); }

需要注意，真实平台的 Webhook 消息格式差异很大。有的平台需要msgtype字段，有的平台要求按markdown或text格式组织内容，有的平台要求签名校验。编写集成代码之前，务必先查阅对应开放平台的接入文档，并且在小范围测试群验证通过后再应用到正式群。

5.3 邮件摘要提醒

除了 IM 通知，邮件摘要也是一个重要渠道。对于不经常打开 IM 的同事，可以设置每日或每周摘要，把过去一天或一周内被 @ 提及、线程状态发生变化的内容汇总后发到邮箱。

邮件摘要的实现思路很简单：定时任务扫描 notifications 表，按用户维度聚合未读通知，然后调用邮件服务发送。生成摘要时要注意控制频率和内容长度，否则用户会很快产生邮件疲劳，反而降低工具使用意愿。

6. 常见问题与排查思路

在实现和落地过程中，有一些问题出现频率很高。下面整理成表格，方便快速定位。

另一个常见的坑是 WebSocket 连接生命周期管理。连接建立后，要妥善处理 afterConnectionClosed，避免把已经关闭的 Session 还留在内存集合里，否则会出现内存泄漏。每次推送前也要检查session.isOpen()。

消息分页也容易踩坑。如果使用传统的 OFFSET 分页，当用户翻到很深的页时，数据库需要扫描并丢弃大量行，响应速度会明显下降。建议列表页统一使用基于游标的分页方式。

7. 最佳实践与工程建议

7.1 上下文与结构化

产品团队沟通工具的核心价值不是把聊天从 IM 搬到另一个工具里，而是让沟通过程变得结构化。

建议在创建线程时就明确以下几个字段：

• 线程标题，要能表达一个明确的问题或需求。
• 线程描述，用简洁的格式说清背景和目标。
• 关联成员，方便后续订阅和通知。
• 状态信息，让所有参与者一眼看到当前进度。

在代码层面，应该把线程状态设计成可扩展的枚举，而不是散落在业务逻辑里的字符串常量。这样后续增加状态时，只需要修改枚举和对应展示配置。

7.2 权限与安全

权限设计要遵循最小权限原则。普通成员可以查看自己加入的团队空间和线程；管理员可以管理成员；owner 可以删除空间或转移所有权。

接口层面要做到两层校验。第一层是认证，确认调用者是谁。第二层是授权，确认调用者是否对该资源有操作权限。比如发送消息前，不仅校验登录状态，还要校验该用户是否属于线程所在团队空间。

数据库操作要特别注意两点：一是所有删除操作必须先备份或标记删除，不要物理删除重要讨论内容；二是消息内容可能包含敏感信息，数据库连接和生产配置不要提交到代码仓库，建议使用环境变量或配置中心管理。

7.3 通知策略

通知功能做得好不好，直接决定工具能否长期存活。

建议把通知分成两类。实时通知用于 @ 提及和直接回复，需要即时推送。汇总通知用于订阅线程的进展更新，可以按照用户设定的频率聚合发送。

用户应该可以对单个线程设置静默，也可以设置全局免打扰时间段。例如产品经理每天下午要集中评审，可以设置两点到四点不接收非紧急通知。避免通知成为新的负担，是“enjoyable”体验的关键。

7.4 性能与发布

初期用户量小，单机部署加一个 PostgreSQL 实例就能支撑。数据量增长后，优先从索引和分页优化开始，不要急着引入复杂中间件。

生产发布要走灰度流程。先在一部分团队空间开启新功能，观察日志和用户反馈，再逐步放开。涉及数据库结构变更时，先在小库验证，编写回滚脚本，确保发布失败时能快速恢复到上一版本。

实时通信模块要监控连接数、消息推送延迟、断开重连次数等指标。如果发现推送延迟持续升高，优先排查是否有消息积压，以及推送逻辑是否做了无效循环遍历。

7.5 从 MVP 到产品化

如果只是验证想法，不建议一开始就把所有功能做完。一个 MVP 只需要几十行建表 SQL、三四个接口和一个最简单的聊天页面。

第一步，跑通创建线程和发送消息。第二步，接入 @ 提及通知。第三步，接上 WebSocket 实时推送。第四步，把关键事件推到 IM 群。

每一步都能单独上线验证。等用户确实开始依赖这个工具了，再考虑全文检索、移动端、数据统计等进阶能力。

8. 总结与下一步学习建议

这篇文章从产品团队沟通的痛点出发，完整拆解了一款协作工具的最小实现方案。重点可以归纳为几个方面：线程化沟通的数据模型如何设计；创建线程、发送消息、@ 提及通知这些核心接口如何实现；WebSocket 如何接入实时消息；以及如何通过 Webhook 与飞书、钉钉、企业微信等现有 IM 工具配合使用。

代码示例可以直接作为内部工具或毕业设计的起步代码，但要注意版本适配。Spring Boot、PostgreSQL、React 的版本差异会影响具体写法，遇到报错时优先检查依赖版本和配置项。

如果你想继续深入，建议按下面三条路线选一条来学：

• 后端方向：学习 Spring Security 统一认证授权、消息队列削峰填谷、Elasticsearch 全文检索。
• 前端方向：学习富文本编辑器集成、消息虚拟滚动、移动端离线推送。
• 产品方向：研究通知聚合策略、轻量级工作流、团队协作数据看板。

做这类工具最容易犯的错，是功能越加越多，但核心沟通链路没走通。建议后续迭代时先问自己一个问题：这次改动是否让用户更愿意回来使用工具？如果答案不确定，就先把需求放一放。先用最小闭环把团队“用起来”，再谈功能的深度和复杂度。