企业官网建设流程全解析

两台设备的编辑如何安全合并：ZenNotes云同步与三方合并冲突解决机制解析

【免费下载链接】zennotesKeyboard-first local Markdown notes with Vim motions, diagrams, and MCP integration.项目地址: https://gitcode.com/gh_mirrors/zenn/zennotes

ZenNotes 是一款本地优先的 Markdown 笔记应用，支持 Vim 键盘操作、图表与 MCP 集成。它的云同步（Cloud Sync）功能能让笔记本和手机上的同一篇笔记安全合并：互不重叠的修改会自动三方合并（three-way merge），只有两台设备改了"同一句话"时，才需要你做一次明确的选择——整个过程不会丢失任何一方的内容。

本文面向普通用户，用通俗的方式讲清楚 ZenNotes 云同步冲突解决机制的运作原理，以及当你看到"1 file needs review"提示时该怎么做。

为什么两台设备同时编辑容易"撞车"？

想象这个场景：你在笔记本电脑上修改了笔记的开头，出门后又用手机改了同一篇笔记的结尾，两边都没有先同步。

很多同步工具遇到这种情况会做两件令人头疼的事：

• 直接让后保存的一方覆盖先保存的一方，另一方的修改悄悄丢失；
• 生成一个xxx (cloud conflict)的副本文件塞进你的笔记库，之后还混进搜索、任务列表和备份里，清理起来很麻烦。

ZenNotes 的做法是第三条路：先自动合并能合并的，合并不了的绝不猜，而是排队等你决策。这套机制在 2.44.0 版本发布说明 中有完整描述，设计规格见 docs/specs/cloud-conflict-resolution.md。

云同步如何三方合并：自动合并互不重叠的修改

ZenNotes 的自动合并基于经典的**三方合并（diff3）**算法，核心逻辑在 packages/shared-domain/src/cloud-sync-merge.ts 中实现。它同时持有三个版本：

合并规则非常简单：

1. 行级差异比对——把本地版本和云端版本分别与基准版本逐行对比，找出各自的"改动块"；
2. 改动块不重叠 → 自动合并——比如你改了第 3 段、手机改了第 8 段，两处改动直接拼在一起，作为新的共同版本上传，两台设备最终收敛到同一份内容，你全程无感知；
3. 改动块重叠 → 进入冲突队列——如果两边改了同一行或相邻行，ZenNotes 不会擅自选一个"赢家"，而是把这段改动标记为待决冲突。

细节上它还有不少贴心设计：自动识别 CRLF / LF 换行符，避免 Windows 和 macOS 设备互相"制造"差异；基准文件最后一行没有换行符时也不会被错误地"粘"到下一行。这些边界情况的测试全部包含在 packages/shared-domain/src/cloud-sync-merge.test.ts 对应套件中。

同一处被修改时：冲突队列与手动解决步骤

当确实发生重叠编辑时，ZenNotes 会在工作区状态栏显示一个常驻的入口："1 file needs review · Review now"。同样的队列也能从 设置 → Cloud、命令面板（Review Cloud Sync Conflicts）或 Vim 快捷键Space r打开。

打开后，你会看到等待处理的全部文件列表，界面用大白话标签（而不是版本号或哈希值）呈现三个版本，并给出高亮标记的合并预览。你可以对每一处模糊改动单独选择：

• Use this device—— 采用本设备的写法
• Use other device—— 采用另一设备的写法
• Keep both changes—— 两处改动都保留

也可以直接编辑合并后的完整笔记，最后点Save combined note保存。队列会按文件逐个处理，解决完一个自动跳到下一个；多文件的冲突也走同一个持久化队列，不会散落各处。

第一次同步：诚实的两个版本

如果这篇笔记从来没有共同基准（例如第一次把两个库接入云同步），ZenNotes 不会假装能推断出合并结果。它会完整展示两个版本、解释"为什么无法判断哪个更新"，让你选择保留其一、以你起的名字两者都保留，或手动合并。用完整版本替换另一版本时还需要一次独立确认——宁可多问一句，不可悄悄丢字。

稍后处理：进度不会丢

没想好？点Finish later。关闭前会弹出明确警告并要求确认，且会先保存你当前的编辑草稿。此时：

• 你的本地笔记依然在原处，可见、可编辑；
• 云端对比版本、上次同步版本和草稿存放在私有应用存储里，绝不会变成笔记库里的"影子文件"，也不会混进搜索、备份或第三方文件同步；
• 冲突文件的同步暂时暂停，其他所有笔记照常同步，互不阻塞；
• 下次重新打开队列时，草稿和进度原样恢复。

另外，笔记等待决策期间，其中的任务数据会从 Tasks、日历和看板视图中暂时隐去，避免两台设备上出现"分身任务"；冲突解决后自动恢复。

安全保证：为什么这个机制值得信任

ZenNotes 在 docs/specs/cloud-conflict-resolution.md 的 Boundaries 一节中明确了几条不可逾越的底线，值得普通用户了解：

• 永不静默选定赢家——重叠修改必须经你确认；
• 过期操作无效——保存合并结果前，会重新校验本地文件和云端版本的最新状态，防止一次"过期的选择"覆盖掉你刚做的新编辑；
• 所有版本可恢复——冲突跨越应用重启、多次同步周期都逐字节可恢复；
• 旧版冲突文件不自动删除——早期版本留下的(cloud conflict)副本只会被识别并建议你手动审查，ZenNotes 绝不替你删除；
• 删除、移动、二进制文件、文件重名等所有类型的冲突，都走同一个带完整选项的持久化队列。

同步协调器的排队、暂停与恢复行为由 packages/shared-domain/src/cloud-sync-coordinator.ts 负责，界面部分在 packages/app-core/src/components/CloudConflictDialog.tsx 与 packages/app-core/src/components/CloudPendingConflictResolver.tsx 中。

总结：一套"自动化 + 人工决策"的安全合并模型

一句话概括 ZenNotes 云同步的冲突解决哲学：

能自动合并的绝不打扰你，必须人决定的绝不猜，所有版本在你点确认之前都安全保存。

对于在多台设备间使用 Markdown 笔记的用户来说，这套机制意味着：日常多端编辑完全无感，真正冲突时有一个清晰、可暂停、可恢复的决策入口，而不是满库的重复文件和丢失的段落。如果你想进一步了解整个应用的本地优先架构，可以阅读 docs/explanation/how-zennotes-works.md。

【免费下载链接】zennotesKeyboard-first local Markdown notes with Vim motions, diagrams, and MCP integration.项目地址: https://gitcode.com/gh_mirrors/zenn/zennotes