如果你在用 Syncthing 给两台以上的设备同步 Obsidian 笔记库、工作文档或任何"活的"文件夹，大概率迟早会遇到这一幕：库里多出一个名字又长又怪的文件，长这样：
`项目方案.md.sync-conflict-20260821-091500-AB12CD34.md`
第一眼看像乱码，第二眼发现它和正在写的那篇笔记同名，心里咯噔一下：数据是不是丢了？
先给结论：别慌，数据基本没丢。这个文件叫冲突文件（conflict file），不是事故，而是 Syncthing 内置的一道"安全网"。今天把这套机制讲透：它什么时候出现、两份内容到底留了哪份、为什么它会扩散到所有设备，以及怎么清理、怎么预防。
一、冲突文件什么时候出现？条件只有一个
官方的触发条件只有一条：同一个文件在两台设备上都被修改过，且两边的内容确实不一样。官方的处理方式是选一份保留，另一份改名成冲突副本。Syncthing 官方文档注意，这里的"同时"不要求你真的在同一秒编辑，只要求两边的改动"还没来得及互相同步"。这恰恰是最常见的情况：
这时你在另一台设备上动了同一个文件，等设备重新连上，Syncthing 发现"这个文件两边有两个不同版本"，冲突流程就启动了。按官方文档，文件监视器默认会把变更积攒约 10 秒再处理，删除类变更还会再延迟约 1 分钟通知对方——所以哪怕两台设备都在线，快速来回编辑也存在一个小的"冲突窗口"。
二、谁"输"？官方文档写得明明白白
冲突发生时，Syncthing 不做合并，而是选一份原样保留，把另一份改名保留。判罚规则有三条：
修改时间不同：修改时间较旧的那份"输"，被改名为 `原文件名.sync-conflict-日期-时间-设备标识.扩展名`；
修改时间恰好相同：设备 ID 前 63 位数值较大的一方保留，另一方改名（听着玄学，本质就是个随机决胜）；
一边改了内容、一边把文件删了：哪边"赢"哪边生效，但输掉的那份依然会被改名保留，不会凭空消失。
重点看第三条：连"删除"赢下冲突时，文件都不是真的没了，而是以冲突副本的形式留着。Syncthing 官方文档这套设计思路从头到尾是一致的——不替你悄悄丢任何一个字节，把决定权还给你。
三、两个反直觉的事实
事实一：冲突文件不会自动清理，还会扩散到所有设备。官方文档明确说，冲突文件一旦生成，就被当作普通文件对待，会被同步到共享这个文件夹的所有设备上——因为 Syncthing 无法替你判断"你到底想要哪份"，干脆两份都给你。Syncthing 官方文档你不处理，它们就会一直在，手机、电脑、NAS 上哪都跑不掉。
事实二：设备越多，局面越乱。B 站一条"Obsidian+Syncthing 使用一个月"教程视频的评论区，有位老玩家把三台设备两两互连的场景拆得很细：文件在多设备间的流转路径一多，出现"两台设备各自拿着不同未同步改动"的机会就更多，重复文件和冲突副本也比两台设备时更常见。他给出的思路值得参考：把"两两互连"改成星形结构，选一台常年在线的设备（NAS 最合适）做中转枢纽，其他设备只和它连，文件流向收敛成单向。哔哩哔哩代价是枢纽必须靠谱在线，枢纽一断，其他设备之间如果没配对就同步不了，适合取舍。
四、先分清：你看到的"分身"，可能根本不是冲突
这是最容易踩错的一步。动手前先看文件名里有没有 `.sync-conflict-`：
有：真冲突，按本文处理；
没有，只是两台设备各有一份、新旧不一：多半不是冲突，而是压根没同步上——手机端被杀后台、只在 WiFi 下才连、对端长期离线。打开 Syncthing 的 Web 管理界面（默认端口 8384）看设备状态，不是"最新"而是断开或带同步进度，就先让它同步完，很多"分身"会自己消失。
社区里"没同步上"其实比"冲突"高频得多。小红书上有用户吐槽微力同步和 Syncthing"间歇性掉线最蛋疼"，说这并非一劳永逸的系统，还是需要轻量级的手动维护。小红书B 站评论区也有人干脆把文本笔记改用 git 管理，说这是碰到同步问题后想到的解决办法——这些都是真实用户踩过坑之后的气话和出路。哔哩哔哩
五、已有的冲突文件，怎么收尾
三步走：
对比：把原文件和冲突文件并排打开，文本直接用支持 diff 的工具（VS Code、Beyond Compare 都行），看两边各加了什么；
合并：把需要的内容手动并进原文件；
删除：在任意一台设备上删掉冲突文件，删除会随同步扩散到所有设备。
两个提醒：删之前一定确认合并完成，删除的扩散是双向的，之前专门讲过"把 Syncthing 当备份"时删一张照片全端跟着没的机制，这里同理；没把握就先整库拷一份再动手，几分钟的保险不亏。
六、预防清单：把冲突压到接近零
养成"同步完再换设备"的习惯：合盖、锁屏前瞄一眼托盘图标或 Web 界面是不是"最新"状态，就几秒钟；
用 .stignore 排除高频变动的"状态文件"。Obsidian 用户可以在库根目录放一个 .stignore，官方要求这个文件必须放在同步文件夹的根目录，放在其他位置不会被应用。Syncthing 官方文档推荐排除的内容：
```
.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash
```
workspace 这类文件记录的是"开了哪些页、侧栏多宽"，Obsidian 每次打开都在重写，是冲突重灾区，排除掉几乎是 Obsidian 同步圈的共识；
安卓端给足后台权限：Syncthing-Fork 这类客户端要关掉电池优化、允许后台运行，否则手机端改动永远"慢一步"，等于在制造冲突；
三台以上设备考虑星形结构，让常开的 NAS 或家庭服务器做中转；
在主设备上开文件版本控制当保险：比如"简单文件版本控制"保留最近 5 个版本，默认存在 .stversions 目录里。三种策略的差别一句话：垃圾桶式只留最后一份，简单式按份数留，阶段式按时间梯度留（近 1 小时每 30 秒留一份、近 1 天每小时一份、近 30 天每天一份，之后每周一份）。注意官方明确说过：版本控制只对"从其他设备收到的变更"生效，它保的是远端覆盖，你自己本地手滑它不兜底，所以上一步说的"清理前备份"别省。Syncthing 官方文档
七、最后说句实话：有的场景别硬撑
Syncthing 的冲突策略本质是"我不合并，两份都留，你来裁决"。对"一次只在一台设备上编辑"的用法，这套机制足够省心；但如果你的场景是多设备高频同时编辑，换 Self-hosted LiveSync、Obsidian 官方同步这类"合并型"方案更合适——社区里有人用 LiveSync 超过 9 个月，评价很稳。
B 站评论区有条被顶上来的总结很犀利：Syncthing 更适合"不太会变动的文件"，比如程序、图片素材；高频变动的文本要更小心。哔哩哔哩这句话略绝对，但方向没错。
顺手同步一下版本动态：截至目前，稳定版是 8 月上旬发布的 v2.1.3，v2.1.4 的两个 RC 版本 8 月 19 日和今天刚先后放出，冲突处理机制在 2.x 系列没有变化。还在 v1 的话，官方更新重心早已在 2.x，建议备份配置后择机升级。
如果你也被冲突文件折磨过，评论区聊聊你是怎么收尾的——你清理的可能不是文件，是别人没保存的毕业论文。
