多人白板协作里的“橡皮擦事故”几乎是每个用过在线白板的团队都绕不开的噩梦。A同学辛辛苦苦画了十分钟的流程图B同学只是想把画布角落的草稿清掉结果橡皮擦轻轻一划A的箭头、文字、边框全部“蒸发”一屋子人愣在原地。我做了几年协作工具的前端开发这类问题在需求评审会、方案共创会、线上培训课上反复上演而且它一点也不“有趣”——一旦发生轻则打断思路重则导致整场会议节奏崩盘。这篇文章想聊透“多人同时书写时如何避免橡皮擦互相删”这件事。我会从根因拆解讲起把归属模型、锁定机制、协作层隔离、并发控制这几种主流方案逐一讲透再给出一版可以直接落地的最小实现最后分享一些我在真实项目里踩过的坑和产品权衡建议。适合产品经理、协作工具开发者以及所有被白板橡皮擦坑过的人。1. “互相删”灾难到底怎么发生的1.1 一次典型事故的全程复盘真实场景往往长这样需求评审会上产品经理一边在白板上画新的用户流程图一边跟开发讲交互逻辑。突然运营同学想清理右上角之前活动方案的贴纸随手拿起橡皮擦横着一划结果画布上所有贴纸没了产品经理刚落笔的箭头、矩形边框、手写文字也被擦得七零八落。整个会议室瞬间安静三秒然后就是一连串的“你怎么把我画的删了”“我就想擦个贴纸”“算了重新画吧”。这个场景在Miro、Excalidraw、Figma Jam、腾讯会议白板等工具里都很常见。我复盘过不少类似事故发现规律高度一致出事的人都不是故意的工具也没有崩溃纯粹是“操作直觉”和“产品权限”没对齐。橡皮擦在传统白板里是纯粹的物理工具谁拿起板擦谁就能抹掉一切数字白板如果完整复刻这个直觉就忽略了“多人在同一块画布上协同”这个前提。事故还有一个隐蔽升级版有些人为了躲避误删把内容画在画布边缘结果另一个人为了看清全局按了“适应画布”或者缩放画布橡皮擦的笔迹坐标在全屏上下文里换算出错直接把中间区域的重要内容批量“扫平”。这种技术性误删比手动误删更让人崩溃因为它看起来完全没有人为意图。1.2 问题本质共享画布上的操作边界把“互相删”拆开看它实际是三类问题的叠加。第一类数据层面。所有元素都躺在同一个房间ID下没有任何归属标识。元素不知道自己是哪个用户创建的服务端也不知道。橡皮擦拿到一个坐标把所有命中的元素一视同仁地标为“待删除”。这时候“删别人的”和“删自己的”在代码层面根本没有区别。第二类权限层面。橡皮擦操作没有做权限校验或者校验粒度太粗。有些人觉得“只要不是viewer角色就能擦”这个粒度解决不了团队里大家都是editor的情况。绝大多数评审会里所有参会者都是editor那么权限校验形同虚设。第三类并发层面。多端同时操作时如果删除操作不经过任何冲突合并策略就会出现“客户端A删掉了元素X但客户端B的本地状态里还持有XB下一次同步又把它写回来”的幽灵复活问题。用户看到的结果就是“我明明擦掉了怎么又出现了”然后继续擦反复拉锯。这三个层面不是互相独立的。数据层没有归属权限层就无从判断权限层没做校验并发层再稳也阻止不了“合理但误伤”的删除。要解决问题不是改一行代码的事而是要把删除操作从“物理行为”升级成“受控操作”。2. 四类防“互删”方案逐个摸底2.1 按元素归属隔离谁画的归谁擦最直接的做法是给每个元素加一个ownerId删除时判断操作者与元素ownerId是否一致。这个思路很像自习室的座位分配桌子是公用的但抽屉里的笔记本是私人的你无权扔掉别人的笔记本。实现成本很低改动也小。在元素数据结构里加一个userId字段橡皮擦删除流程里过滤一遍即可function shouldAllowErase(element: Element, userId: string): boolean { if (element.ownerId userId) return true; if (isCanvasAdmin(userId)) return true; // 管理员保留擦除一切的能力 return false; }这个方案的缺点是容易走极端。团队协作里经常有“我帮你擦掉这个错别字”“我帮你清理一下重叠的贴纸”这类善意操作如果严格隔离这些操作全部被禁止用户会感觉很死板。所以我见过不少产品采用“默认禁擦主持人可以一键切换为全员可擦”的折中设计既保证安全又不至于把协作变成互相喊话。归属隔离解决的是“我能不能擦你的东西”但还有一个衍生问题需要一起考虑如果内容是从模板复制的owner算谁的我的经验是模板内容要单独标记一个systemOwner身份否则会出现“这个背景框是系统发的谁都不能擦又谁都觉得应该由自己管”的尴尬。2.2 关键元素加锁想误删都没机会归属隔离是一种基于身份的约束锁定机制则是基于“特殊状态”的强约束。元素被标记locked之后任何人——包括创建者自己——在默认状态下都不能删除它、移动它。想改动必须先解锁。这个机制的现实映射是工地上的“承重墙”。墙不能拆这件事不是基于“谁砌的谁拆”而是基于“这是结构安全线”。白板上的背景底图、培训课件框架、评审会议的决议结论区都属于这种“承重墙”级内容一旦被误删整个协作语境直接崩掉。实现时要把锁定判断放到权限链最前面因为它优先级最高。我的习惯是写一个顺序固定的决策链const Decision { ALLOW: allow, REJECT: reject, }; function decideErase(element, user, canvasPolicy) { // 1. 画布级只读 if (canvasPolicy.readOnly) return Decision.REJECT; // 2. 元素锁定保护 if (element.locked) return Decision.REJECT; // 3. 归属校验 if (element.ownerId user.userId) return Decision.ALLOW; // 4. 全局擦除权限主持人/管理员 if (user.permissions.includes(canvas.erase.any)) return Decision.ALLOW; return Decision.REJECT; }锁定值得注意的一个细节是组合场景。用户把一组合格元素组合成组然后锁定其中某一个这组应该整体锁定还是部分锁定我做过一次错误版本只锁定单个子元素结果用户通过整体拖动把这个组拖走锁定形同虚设。后来改成“组合内任一元素锁定则整个组合不可被整体删除”这才堵住漏洞。2.3 协作层隔离每人一层画布更进一步的做法是把白板拆成多个“层”每个参与者拥有自己的专属层层之间默认不可互删。这个方案接近PS里的图层概念也接近某些白板工具的“跟随模式”叠加。协作层的优势是彻底隔离互删适合多人同时各自产出的场景。比如培训课里每个小组一块任务区域各画各的最后可以把层合并起来展示。同时层可以设置可见性主持人可以选择性隐藏某层避免信息干扰。代价是复杂度明显上涨。层与层之间如果只是互不干扰那跟多块白板没有区别可协作工具的魅力恰恰在于跨层互动。你需要额外设计层的合并、层的复制、层的权限转移、层内元素被引用时的归属问题。这通常不是一次迭代能做完的需要投入比较长的研发周期。如果团队已经有基础框架我的建议是先别直接上完整的分层系统。可以做一个简化版每个用户一个透明逻辑层画布保存时把这些层拍平仅在“擦除阶段”按用户过滤层内元素。这个简化版能快速解决互删痛点后续再迭代完整的分层管理。2.4 底层并发控制用CRDT语义管住删除归属隔离、锁定、分层解决的都是权限边界但还有一个更底层的问题并发同步。两个客户端都在离线状态下删除了同一个元素重新联网后谁的删除生效如果同步模型是“最后写入覆盖”很可能出现删除状态被一个旧快照回滚导致元素“复活”。现代协作白板大多采用CRDT方案来保证多端收敛Yjs和Automerge是这个领域比较常见的库。CRDT里每个元素都有全局唯一的ID删除操作是一个逻辑删除——它不会物理清除数据而是插入一个“墓碑标记”来表示该元素已被删除。这种设计保证了并发删除时不同客户端最终能收敛到同一个状态不会出现数据抖动。我最初做协作白板时想当然地以为用上Yjs就万事大吉后来发现CRDT只解决一致性问题不解决业务语义问题。也就是说CRDT层面它根本不管“A能不能删B的元素”只要删了它就忠实同步给所有人。所以正确的架构是CRDT负责底层状态收敛上层再叠一层权限决策链两者各司其职。用Yjs做底层时权限层要注意一个坑不要把权限判断只写在自己的客户端里否则你拦住了自己没拦住别人的恶意或异常请求。所有删除决定必须同时传递给协作服务端由服务端做权威判断再分发给客户端。这里没有捷径。方案实现成本用户感知适用场景元素归属隔离低直观需要适应全员可编辑的评审白板关键元素加锁低被动保护重要元素、背景模板协作层隔离高灵活学习成本高教学、培训、多人同屏CRDT/OT合并高无感一切多人编辑的底层能力3. 动手实现一个防互删的橡皮擦逻辑3.1 先定义一份带归属和状态的元素模型实现“防互删”的第一步是让元素“认识自己是谁”。一个可用的基础模型长这样export interface BaseElement { id: string; type: shape | path | text | image; ownerId: string; locked: boolean; x: number; y: number; width: number; height: number; version: number; // 乐观锁版本号 groupId?: string; // 组合标识 createdAt: number; updatedAt: number; }ownerId是“互删”问题的核心有了它橡皮擦才能判断操作者和元素的关系。locked是锁定标记保护“承重墙”元素。version和updatedAt则用于并发冲突检测后面会讲到。模型定义阶段最容易踩的坑是集团队和组织维度。如果白板是团队创建的那团队负责人应该算owner还是普通用户如果属于某个团队空间那团队内所有人擦除权限是否一致我的建议是元素至少记录userId和teamId两个维度产品上把“团队内容”和“个人内容”区分开权限判断时再按具体场景选择维度。3.2 橡皮擦命中检测与权限决策橡皮擦本质是用一个笔画路径或矩形区域来收集“命中元素”然后对命中的每个元素做权限决策。关键代码不是命中检测本身而是决策顺序。export interface EraseRequest { requester: Collaborator; target: ElementSnapshot; strokeBounds: Rect; } export interface Collaborator { userId: string; role: owner | admin | editor | viewer; permissions: string[]; } export function decideErase(req: EraseRequest, canvasPolicy: CanvasPolicy): boolean { // 1. 画布只读直接拒绝 if (canvasPolicy.readOnly) return false; // 2. 命中目标被锁定直接拒绝 if (req.target.locked) return false; // 3. 元素所属者是自己允许擦除 if (req.target.ownerId req.requester.userId) return true; // 4. 拥有全局擦除权限管理员/主持人允许擦除 if (req.requester.permissions.includes(canvas.erase.any)) return true; // 5. 其他情况默认禁止 return false; }这里有三个细节值得展开。第一查看器viewer角色的权限在第一步就被拦截不需要单独写一条难看的判断。第二组合元素的判断要放在元素判断之前用户擦了一个组合中的子元素需要先递归检查组合的所有子元素如果组合内任一元素locked整组禁止擦除。第三命中检测的坐标转换必须考虑画布缩放。橡皮擦笔画记录的是屏幕坐标必须经过viewport变换换算到画布坐标否则在高缩放下会“打偏”把不想擦的内容扫进来。这是开头说的那种“全画面扫描事故”的技术根源。3.3 处理并发冲突操作日志与乐观锁权限判断做完还差最后一道保险并发冲突。最简单的有效手段是给每个元素加version版本号。客户端发起删除时请求里带上它看到的version服务端校验此version是否等于当前version相等才执行删除并递增版本号。如果不等说明这个元素已经被别人改过直接返回409冲突前端提示用户“内容已变化已为你刷新”。async function eraseElement(roomId: string, elementId: string, expectedVersion: number) { const element await db.findOne(roomId, elementId); if (!element) return { ok: false, reason: not_found }; if (element.version ! expectedVersion) { return { ok: false, reason: version_conflict }; } await db.updateOne( { roomId, elementId, version: expectedVersion }, { $set: { deleted: true, updatedAt: Date.now() }, $inc: { version: 1 } } ); return { ok: true }; }为什么锁定了的元素被删掉后又“复活”很多时候就是因为并发状态不一致。客户端A删除元素后客户端B还保留着旧快照如果B后把自己的全量同步推上去A的删除标记就会被覆盖。用了带版本号的条件更新删除和更新都会被严格排序没有哪个客户端能靠旧状态翻盘。删除操作最好做成逻辑删除而不是物理删除。白板协作里的撤销是个高频需求用户误删之后的第一反应是CmdZ。如果删除是物理清除撤销逻辑就很难实现。我的做法是维护一个操作日志每次删除记录一个操作条目用户可以撤销的对象包括元素快照、操作时间、操作者、涉及组合关系。撤销时回放日志需要重新执行一次权限校验防止用撤销绕过他人锁定。4. 产品落地不是所有白板都需要同样策略4.1 不同场景下的方案选型技术方案没有绝对优劣取决于白板的使用场景。小团队共创为什么“元素归属”就够用因为人少团队关系熟误删后喊一声就能恢复不需要重密度权限设计。大型公开会议则不同参与人可能来自多个公司没有共同的信任基础这时“主持人专属擦除权 普通用户不可擦他人内容”就非常必要。在线教学场景通常需要老师控制整体节奏协作层隔离配合可见性开关会更合适设计评审则是另一回事评审对象往往是锁定过的设计稿擦除本身就该被禁止应该引导学生用评论、批注、贴纸来表达意见而不是直接修改画布。场景推荐组合理由小团队评审会归属隔离 管理员可全擦低成本解决大部分误删大型跨团队会议主持人模式 锁定参与方互不信任需要权威控制在线教学/培训协作层隔离 层可见性老师按小组分发画布区域灵活控场设计稿评审锁定 评论模式替代擦除保护设计内容引导非破坏性反馈4.2 我在真实项目里踩过的四个坑第一权限校验只做前端后端被绕过。我把所有删除判断写在了客户端觉得操作都走WebSocket很方便。结果有人直接构造WebSocket消息绕过界面发了一个删除请求服务端照单全收。那次事故之后所有关键操作都改成服务端权威校验客户端只负责展示决策结果和优化体验。第二锁定和组合的冲突。前面提到的“组内锁一个整组可拖走”的问题我实际踩过。修复后才发现类似问题不止一处锁定元素被包含在批注分组里、被复制粘贴后丢失锁定状态这些都属于边缘用例必须做系统性的回归测试。第三撤销绕过锁定。用户B锁定的元素被用户A误删用户A立刻执行撤销把元素恢复回来——这等于绕过了锁定机制。解决方案是撤销也要走权限决策链撤销操作恢复的元素如果处于锁定状态必须额外弹窗确认或者直接禁止该次撤销。第四过度锁定的反噬。上线锁定功能后我发现很多用户把所有内容都锁上了。结果那场评审会上谁都没法修改任何元素协作效率反而骤降。这提醒了我锁定是保护机制不是默认状态。后来我在产品里增加了一个“锁定提示”当用户锁定超过一定比例元素时会提醒他“锁定内容过多团队成员将无法修改”。4.3 常见问题速查表现象可能原因建议处理橡皮擦把同事画的内容擦没了无归属校验引入ownerId检查建立决策链擦完后内容又“复活”并发同步冲突使用版本号/乐观锁或CRDT元素锁定后自己也无法修改权限粒度太粗给创建者保留解锁能力设置了只读还是被改校验未在后端执行服务端强制校验数据与操作擦除时连带删掉无关内容坐标转换未考虑缩放把屏幕坐标经viewport换算到画布坐标锁定元素通过撤销被恢复撤销绕过权限链撤销也走完整的权限决策5. 最后分享点个人体会“防互删”这件事技术上和产品上需要同时发力。技术层解决“能不能删”产品层解决“该不该删”。我目前比较推荐的做法是“默认归属隔离 主持人一键开启全员可擦除 重要元素手动锁定”的组合拳。它没有把权限收紧到扼杀协作的程度也没有为了协同流畅就把所有人都曝露在误删风险里。这套方案在几十场内部评审会上跑下来基本没有再出现过开头那种整个画布被抹平的惨剧。如果你也被白板橡皮擦折磨过可以先挑最轻的方案——给元素加ownerId后端强制校验删除权限——先落地。很多时候问题就那么解决了。