Firebase Realtime Database对并发连接数有明确的硬性限制，免费Spark套餐约为100个并发连接，付费Blaze套餐也不过20万左右（可申请提升）。当应用的在线用户量逼近这个数字时，最典型的表现就是新客户端报错无法建立WebSocket连接，旧客户端数据不再实时同步。要突破这个瓶颈，需要先弄清楚Firebase到底怎么计算连接数，再从连接管理、数据架构、请求模式三个层面做优化。
先理解连接数的计算规则
很多人以为连接数等于用户数，这个理解是错的。Firebase的并发连接数指的是同时打开的WebSocket或长轮询通道数量，一个浏览器标签页、一个移动端App实例、甚至一个Node.js服务端进程，只要保持了对数据库的监听，就各占一个连接。也就是说，同一个用户开了三个标签页，就消耗了三个连接额度。
另一个容易忽视的细节是：只要客户端代码里调用了任何监听类API，比如on('value')或者onChildAdded，连接就会一直保持，哪怕页面切到了后台、用户已经离开。移动端如果不正确处理生命周期，App退到后台后连接未及时断开，会造成大量僵尸连接白白占用配额。
排查时可以先用Firebase控制台的Usage标签页查看current connections曲线，确认峰值出现在什么时间、是否与某个功能上线时间吻合。如果曲线显示连接数远高于DAU，那基本可以断定存在连接泄漏或多标签页滥用的问题。
客户端层面的连接复用与生命周期管理
第一件事是规范连接的打开与关闭。Web端应使用Page Visibility API，在页面不可见时主动断开监听，恢复可见时重连。Firebase JS SDK提供了goOffline()和goOnline()两个方法来实现这个控制。
// 根据页面可见性管理连接
document.addEventListener('visibilitychange', () => {
if (document.hidden) {
firebase.database().goOffline(); // 释放连接
} else {
firebase.database().goOnline(); // 恢复同步
}
});第二件事是合并监听点。不少项目为了图省事，在各个组件里各自订阅数据，导致同一个页面挂了七八个监听器。虽然SDK内部会在同一进程内共享一条WebSocket，但Web端每个标签页是独立进程，多标签场景下连接会成倍增加。合理的做法是建立一个集中式的数据仓库，所有组件从仓库取数据，仓库内部只维持一份监听，页面卸载时统一释放。
第三件事是降低不必要的数据拉取。能轮询的展示类数据不必实时监听，比如排行榜、统计面板，可以用Cloud Functions定时写入聚合结果，客户端每30秒拉一次快照即可，这类一次性读取不需要保持长连接，对连接数几乎零消耗。
架构层面的分流与拆分方案
如果客户端优化后连接数依然吃紧，就要考虑把部分流量从实时数据库挪走了。最直接的方案是冷热数据分离：真正需要实时推送的数据（如聊天消息）留在Realtime Database，只读数据、历史数据全部迁到Firestore或Cloud Storage。Firestore按读写次数计费而不按连接数，天然适合承接大量低频访问。
对于服务端高频写入的场景，不要让每台服务器都直连数据库，而是引入消息队列做缓冲。服务器把写请求丢进Pub/Sub或者Redis队列，由一组专门的worker进程统一写入Firebase，这样无论上游有多少台机器，实际占用数据库连接的只有固定的几台worker。
// 服务端通过单一writer进程集中写入
async function writeTask(task) {
// 所有节点把任务推入队列
await redis.lpush('firebase_write_queue', JSON.stringify(task));
}
// 独立的writer进程消费队列，只占用一个连接
async function writerLoop() {
while (true) {
const [, raw] = await redis.brpop('firebase_write_queue', 0);
const task = JSON.parse(raw);
await admin.database().ref(task.path).update(task.data);
}
}还有一种做法是自建一层WebSocket网关。客户端统一连接到自己的网关服务器，网关再以少量连接订阅Firebase，把变更广播下去。这样连接数从用户规模变成了网关数量级，但要自己处理网关的水平扩展和故障恢复，属于重量级方案，一般在用户量达到数万以上时才值得投入。
迁移决策：什么时候该换数据库
优化是有边界的。如果做完以上所有措施，连接数峰值仍然稳定超过套餐上限的70%，说明业务规模已经超出了Realtime Database的舒适区，此时继续硬扛的成本（开发量加运维复杂度）往往高于直接迁移。判断标准可以参考三点：一是单个连接承载的活跃用户数是否还能提升；二是数据模型是否已经过度拆分；三是团队是否有精力维护自建网关。
迁移路径上，聊天、协作编辑这类强实时场景可以评估Supabase Realtime、自建WebSocket加Redis Pub/Sub等替代品；普通业务数据则推荐Firestore，它的文档模型、查询能力和计费方式都更适合规模化应用。迁移不必一步到位，可以按数据域逐步双写、灰度切流，把风险控制在可控范围内。记住一点：突破连接限制的本质不是对抗限制本身，而是让每个连接发挥出最大价值。