Suitenumerique文档协作冻结问题分析与解决方案

问题现象

在Suitenumerique项目的文档协作场景中，当多个用户(6人左右)同时编辑同一文档时，出现了文档突然冻结的情况。用户能够看到光标移动但无法进行任何编辑操作，这种状态持续约5分钟后自动恢复。该问题在不同浏览器(Safari、Firefox、Chrome等)和不同设备上均有重现。

技术背景

该文档协作功能基于Yjs和ProseMirror技术栈实现，使用HocusPocus作为协作服务器。系统采用了一种特殊的架构设计：HocusPocus仅负责实时更新传播，而文档存储则通过API调用后端/S3实现。

问题根源分析

经过深入调查，发现问题核心在于y-prosemirror的update处理函数中抛出异常时会导致文档状态异常。具体表现为：

1. 当用户A(Alice)修改文档时，变更会发送给其他用户
2. 用户B(Bob)的update处理函数抛出异常
3. Bob会将自己的ProseMirror状态重新同步给其他用户，实际上撤销了Alice的修改

已知触发场景

目前确认有以下两种情况会导致update处理函数抛出异常：

1. 光标位置判断异常

当编辑器处于不可编辑状态且对ProseMirror div应用了user-select: none样式时，selection类型会变为"none"，而y-prosemirror未能正确处理这种情况，导致_isLocalCursorInView函数抛出错误。

2. 相对选区恢复异常

restoreRelativeSelection函数在处理某些特殊情况时可能抛出错误，特别是当两个文档被错误地独立初始化时。

潜在风险因素

除了上述确认的场景外，还存在以下潜在风险：

1. 特殊架构设计：当前系统中HocusPocus仅处理实时传播而依赖独立存储机制，这种实现方式可能在某些边界条件下导致同步问题。

2. 浏览器兼容性问题：旧版浏览器在处理特定DOM操作或CSS属性时可能出现异常行为，进而触发同步问题。

解决方案

针对已确认的问题场景，建议采取以下措施：

1. 增强_isLocalCursorInView函数的健壮性，确保能够处理所有可能的selection类型。

2. 改进restoreRelativeSelection函数的错误处理机制，防止异常传播。

3. 加强客户端错误监控，通过Sentry等工具实时捕获前端异常，便于快速定位问题。

4. 考虑重构协作架构，使HocusPocus直接管理文档存储，减少潜在同步风险。

实施建议

对于技术团队而言，建议：

1. 优先实施已知问题的修复方案。

2. 加强生产环境监控，特别是针对y-prosemirror update处理函数的错误捕获。

3. 在后续迭代中评估架构优化方案，权衡重构成本与系统稳定性收益。

4. 建立更完善的性能指标和异常报警机制，便于快速发现和解决类似问题。

总结

文档协作冻结问题揭示了实时协作系统中异常处理的重要性。通过本次问题的分析和解决，不仅修复了特定场景下的bug，也为系统架构的持续优化提供了宝贵经验。建议团队在后续开发中更加注重边界条件的测试和异常场景的处理，确保协作功能的稳定可靠。