数据库变更订阅：监听表的增删改

数据库变更订阅：监听表的增删改

本节进入实操：如何订阅一张表的数据变更，并按条件过滤只接收关心的事件。这是 Realtime 最常用的能力，也是构建「数据一变、界面即更新」应用的核心。

订阅的基本要素

一次数据库变更订阅通常包含：

• 目标表：监听哪张表（如 orders）。
• 事件类型：关心哪些变更（INSERT / UPDATE / DELETE，或全部）。
• 过滤条件（可选）：只接收满足某条件的变更（如某 user_id）。
• 回调函数：收到事件时做什么（通常是局部刷新界面）。

客户端库提供了统一的订阅接口，把这些要素组合在一起。

订阅全部变更

最简单的形式：订阅某张表的全部变更。

概念步骤：
1. 创建一个针对 orders 表的订阅频道
2. 监听所有事件类型（INSERT/UPDATE/DELETE）
3. 在回调中根据事件类型更新前端状态
​

每当 orders 表有任何行被插入、修改或删除，回调都会被触发，并收到事件载荷，其中包含：

• 事件类型（新增 / 更新 / 删除）。
• 变更涉及的新行数据（删除事件通常只有主键）。
• 表名等元信息。

前端据此判断「是新增了一行，就追加到列表；是更新，就替换对应项；是删除，就移除对应项」。

订阅特定事件类型

多数时候你只关心部分事件。例如：

• 聊天消息表：只关心 INSERT（新消息），不需要 UPDATE/DELETE。
• 文档状态表：只关心 UPDATE（状态变化）。

通过指明事件类型，可以减少无关通知，提高效率。

按条件过滤

订阅时常需加过滤条件，只接收「与自己相关」的变更。典型场景：

• 用户 A 的订单页：只接收 user_id 等于 A 的订单变更。
• 某个具体订单详情页：只接收该订单 id 的变更。

过滤条件让多个用户共存时互不干扰——每个客户端只被自己关心的变更唤醒，避免无谓的刷新。

注意：过滤条件与 RLS 是两层保障。即使你不写过滤，RLS 也会确保用户收不到无权看到的变更；但加上过滤能减少网络与处理开销，体验更好。

一个典型的实时列表更新流程

以「实时订单列表」为例，完整流程如下：

注意第一步仍要主动查询初始数据——Realtime 只推送「订阅之后」的变更，不回放历史。因此实时应用的标准模式是「先查后订」：先拉取当前快照，再订阅后续增量。

处理事件载荷

回调收到的事件载荷结构因事件类型而异：

• INSERT：包含完整的新行。
• UPDATE：包含更新后的行（旧值是否包含取决于配置）。
• DELETE：通常只包含主键，因为行已删除。

编写回调时要分别处理这三种情况，确保界面的增、改、删逻辑都正确。

订阅的启停与生命周期

• 启用 Realtime：目标表需先在项目里启用 Realtime 能力（表级开关），否则订阅收不到事件。
• 建立订阅：客户端连接后即可订阅；订阅会持续到主动取消或连接断开。
• 取消订阅：离开页面或不再需要时，应取消订阅，释放资源。
• 页面切换：组件卸载时务必清理订阅，避免内存泄漏与重复回调。

忘记取消订阅是实时应用常见 bug——用户来回切换页面，订阅越积越多，回调被重复触发。务必在组件销毁时清理。

与初始查询的协调

实时订阅不回放历史，因此「初始数据」要靠普通查询获取。两者的顺序很关键：

1. 先发起查询，拿到当前数据。
2. 拿到结果后再开始订阅。

如果顺序颠倒（先订阅再查询），可能错过订阅建立前发生的变更。更严谨的做法是订阅时记录时间戳，查询时包含该时间点之后的数据，避免任何缝隙。对大多数应用，先查后订已足够。

小结

数据库变更订阅通过「目标表 + 事件类型 + 过滤条件 + 回调」实现；实时应用的标准模式是「先查初始数据，再订后续增量」；事件载荷因类型而异需分别处理；离开页面要取消订阅。下一节介绍 Realtime 的另外两种能力——广播与在线状态，用于无需持久化的实时协作。