Feathers.js 实时 Channel 与事件推送入门
· 阅读需 3 分钟
Feathers.js 在 2021 年让我觉得很有意思的一点，是它不是把实时能力当成“额外插件”，而是直接把 service 事件当成天然的推送源。
这对管理后台、消息通知、协作类页面都很友好。你在 REST 里已经有的 created、patched、removed 这些动作，本来就能表达状态变化，只要再补一层 channel 规则，就能把更新推给对的人。
channel 解决的是“谁该收到消息”
很多人刚接 WebSocket 时，最头疼的不是怎么发消息，而是消息该发给谁。Feathers 的 channel 设计正好把这个问题抽出来了。
你可以按连接所属用户、角色、租户甚至当前房间去分组。这样一来，文章审核通过的事件可以只推给编辑，订单状态变化可以只推给相关客服，不必做全量广播。
事件广播最好只暴露已经稳定的数据
我比较不建议把数据库原始对象直接原封不动推给前端。更稳的做法是:
- 在 after hook 里先清理不该暴露的字段
- 再决定哪些事件值得广播
- 最后把结构稳定的 payload 发到 channel
这样能避免前端在实时链路里收到内部字段，也能减少后续数据结构频繁变动带来的兼容问题。
不是每个 CRUD 事件都值得推
刚开始接入时很容易走极端，要么什么都不推，要么所有 service 操作都推。实际项目里，我更常见的做法是只挑这些变化做广播:
- 用户真正关心的状态变化
- 需要多人同步的列表更新
- 会影响当前页面决策的关键事件
如果只是后台定时刷新能接受的场景，先不上实时链路反而更稳。
前端配合要先想清楚订阅粒度
实时系统做不好，问题常常不在后端，而在前端拿到消息后不知道怎么落状态。比较实用的策略是:
- 列表页只做增量刷新或标记脏数据
- 详情页收到关键事件后主动重新拉取
- Toast 通知和数据更新分开处理
这样既保留实时感，又不会让前端状态管理失控。
小结
Feathers.js 的 channel 和事件机制，最有价值的地方不是“省了一套 WebSocket 代码”，而是它让 service 事件、权限范围和推送对象能够顺手衔接起来。只要先把广播边界收清楚，2021 年的大部分实时后台场景其实都能比较轻松地落下来。