web workers 不直接检测冲突，而是执行ot/crdt等协议定义的耗时计算任务。冲突判定依赖操作建模、排序与一致性算法，需明确操作类型、位置、版本号等上下文，worker仅高效安全地执行校验、变换、合并等纯数据计算。
Web Workers 本身不直接做冲突检测，它只是把协作逻辑中耗时、可隔离的部分（比如 OT 变换计算、CRDT 合并、操作校验）挪到后台线程执行，从而避免阻塞 UI。真正的冲突检测逻辑仍由协作协议决定——核心是操作建模、排序与一致性算法，Worker 只负责高效、安全地执行这些计算。
冲突检测不在 Worker 里“凭空发生”
冲突检测的前提是明确“什么算冲突”。在实时协作中，冲突不是指两个用户同时敲键盘，而是指两个操作无法直接按原样顺序应用而不破坏文档语义。例如：
- 用户 A 在位置 5 插入 “x”，用户 B 同时删除位置 5 的字符 → 位置重叠，需变换或拒绝
- 两人对同一字段赋不同值（如表单中的 price），且无因果依赖 → 值冲突，需策略裁决（保留最新、合并、提示人工）
这些判断依赖操作类型、位置、版本号、时间戳或因果上下文，不是 Worker 自动推断出来的，而是由你集成的 OT 或 CRDT 库定义的规则驱动。
Worker 适合承担的冲突相关任务
一旦检测逻辑确定，大量计算型工作可交给 Worker 处理，提升响应速度和稳定性：
- OT 变换批量计算：收到 10 条他人操作后，Worker 并行对本地 pending 操作逐个执行 transform 函数，生成适配后的新操作序列
- CRDT 状态合并：Yjs 或 Automerge 的 delta 合并、G-Counter 聚合、LWW-element-set 冲突裁决，都可在 Worker 中完成，避免主线程卡顿
- 操作合法性校验：检查插入位置是否越界、删除长度是否超出当前文本长度、version 是否匹配等，这类纯数据验证可异步执行
- 本地暂存队列管理：维护 pendingOps 队列，按 timestamp 排序、去重、截断过期项，不干扰光标渲染
关键配合点：消息结构与线程通信
Worker 要有效参与冲突处理，必须与主线程协同好三件事：
- 操作必须带上下文：每条操作消息至少含 op、index、text/del、clientId、serverTimestamp、docVersion —— 缺少任一字段，Worker 就无法准确判断或变换
- 主线程只传“动作”，不传 editor 实例：Worker 不能访问 DOM 或编辑器 API，所有输入输出都是纯 JSON；主线程把操作对象 postMessage 过去，Worker 返回变换后的 op 数组
- 版本与状态需同步锚定：Worker 内部不维护全局 docState，它只处理离散操作；最终应用结果由主线程根据服务端返回的权威 version 和 rebase 标志来决定是否采纳 Worker 输出
一个典型流程示例
用户快速连打 5 个字符，网络延迟导致其中 2 条操作尚未发出，此时收到他人 3 条变更：
- 主线程捕获输入，生成 5 个 insert 操作，存入 pendingOps，并 postMessage 给 Worker
- Worker 收到他人操作列表，对 pendingOps 中未发出的 5 条执行 OT 变换，输出 5 个新 index 的操作
- 主线程收到 Worker 返回，更新 pendingOps，并在 reconnect 后按新位置发送；同时用服务端返回的 latestVersion 校验是否需丢弃部分操作
