tldraw项目WebSocket连接问题分析与解决方案

问题背景

在tldraw项目的同步功能实现中，开发人员发现了一个与WebSocket连接相关的棘手问题。当使用@tldraw/sync模块并尝试连接自定义服务器时，如果服务器端处理房间创建或加载的操作耗时较长（约100毫秒以上），客户端将无法成功建立连接，陷入持续的"连接中"状态。

问题现象

具体表现为：

1. 首次加载房间时连接失败
2. 客户端持续处于加载状态
3. WebSocket连接始终无法建立
4. 刷新页面后问题消失（因为此时房间已存在于缓存中）

根本原因分析

经过深入排查，发现问题根源在于Fastify WebSocket实现的一个关键特性：如果在进行异步操作之前没有附加消息监听器，那么在异步操作期间到达的消息将会被丢弃。

在tldraw的原始实现中，代码流程是：

1. 首先执行异步的makeOrLoadRoom操作
2. 然后才将socket连接到房间
3. 最后处理消息

这种顺序导致在异步操作期间到达的任何WebSocket消息都无法被正确处理。

解决方案

基于Fastify文档的建议，我们调整了处理流程：

1. 首先立即附加一个临时消息收集器
2. 然后执行异步的房间加载操作
3. 完成加载后建立正式连接
4. 重放收集到的消息

具体实现代码如下：

// 在异步操作前附加临时消息收集器
const caughtMessages: WebSocket.RawData[] = []

const collectMessagesListener = (message: WebSocket.RawData) => {
    caughtMessages.push(message)
}

socket.on('message', collectMessagesListener)

// 执行异步的房间加载操作
const room = await makeOrLoadRoom(roomId)

// 建立正式连接
room.handleSocketConnect({ sessionId, socket })

// 移除临时监听器
socket.off('message', collectMessagesListener)

// 重放收集到的消息
for (const message of caughtMessages) {
    socket.emit('message', message)
}

技术要点解析

1. 消息收集机制：在异步操作开始前就建立消息监听，确保不丢失任何消息。

2. 消息重放：将异步期间收集到的消息在连接建立后重新发送，保证消息处理的完整性。

3. 类型安全：使用@types/ws提供的类型定义，确保代码的类型安全性。

最佳实践建议

1. 在使用WebSocket时，特别是结合异步操作时，应当优先考虑消息处理的顺序问题。

2. 对于关键操作，建议实现消息缓冲机制，防止因处理延迟导致消息丢失。

3. 在性能敏感场景下，可以评估异步操作的耗时，必要时进行优化或拆分。

总结

这个案例展示了在实时协作系统中处理WebSocket连接时需要注意的细节问题。通过理解底层框架(Fastify)的工作原理，并采用消息缓冲和重放机制，我们成功解决了因异步操作导致的连接问题。这种解决方案不仅适用于tldraw项目，对于其他需要处理WebSocket异步连接的场景也具有参考价值。