冲突副本是怎么产生的：文件名规则与大小写冲突

什么时候产生冲突

两台设备同时修改了同一个文件且内容不同，同步引擎不会猜谁对——它保留两个版本：胜者保留原名，败者改名。

败者的新名字

命名模板：

文件名.sync-conflict-日期-时间-设备ID短串.扩展名

例如 报告.docx 变成 报告.sync-conflict-20260101-153022-KMPQXXX.docx。其中的设备 ID 标记了「哪台设备的版本输掉了」。

胜负怎么判

官方文档给出的规则（理解即可，不必记）：

• 修改时间新的赢——输家（修改时间较旧的版本）被改名为冲突副本；
• 修改时间完全相同（多发生在时钟不精确或快速连续操作）时，比较设备 ID 的前 63 位，数值大的一方版本胜出；
• 一边修改、一边删除的冲突，若删除赢了，文件同样改名为冲突副本而非直接消失——数据不无谓蒸发。

冲突副本会被同步出去

这点容易反直觉：冲突副本生成后按普通文件对待，会传播到集群其他设备。官方的理由是冲突在集群里「处处都是冲突」，程序不知道用户想要哪个，干脆都摆出来由人决定。

处理动作就是手动二选一：留下想要的那个，删掉另一个。处理完冲突即告终。

大小写冲突：Windows 与 Linux 混用的坑

同步引擎内部按大小写敏感处理路径，但 Windows、macOS 的文件系统大小写不敏感。当远端出现一个只差大小写的同名文件（readme.txt 与 Readme.txt），本地无法同时容纳两个，程序会报告 case conflict，并只拉取其中一个——哪个拉到「目前不可预测」。

官方的解决方式只有一种：人工定一个统一的名字，在所有大小写不敏感的设备上手动统一。预防优于处理：团队约定命名风格，或在源头用忽略规则挡掉易冲突的变体（见[语法速查(../05-控制同步内容/02-ignore-patterns.md)）。

版本控制里还有一层与冲突的联动：仅接收文件夹上的冲突副本不会外传、还原时一并清除，见[仅接收(../04-共享文件夹/05-receive-only.md)。