Syncthing：多机大文件把我逼急之后，这套开源同步为何留下

一人公司的文件同步，最后都会变成杂技：网盘、U 盘、FTP、Samba、WSL rsync、偶发的 AirDrop。我认真用上 Syncthing，是因为本地模型和工作文件变多之后，旧方案开始频繁失手——要么权限拧巴，要么冲突难查，要么「临时传一下」变成长期债务。

我遇到的真实问题

跑本地 AI 相关工作流时（例如当时大量使用 Stable Diffusion 产出），模型、素材、工程目录体积上来了，同步不再是「偶发拷贝」。我试过 FTP、Samba、WSL 下的 rsync，都能完成某一次传输，但很难变成「改完自动对齐、少操心」的日常。

Syncthing 吸引我的点很朴素：

• 跨 Mac / Windows / Linux
• 去中心化，不一定把整盘隐私放进某一家网盘
• 配好文件夹与设备后，持续同步，而不是每次手工推送
• 开源，出问题能查、能搜、能自己兜底

项目地址：https://github.com/syncthing/syncthing

独立开发者何时值得用

很值得：

• 多台电脑同时开发，需要同步代码之外的大资源（素材、模型、录屏半成品）。
• 对网盘审查、限速、套餐涨价过敏，想把核心目录留在自己设备上。
• 小团队/夫妻店/工作室场景，几台受控设备互相同步。

慎用或别硬上：

• 你需要「共享链接给外部客户随时下载」——网盘/对象存储更合适。
• 你没有基本的冲突处理意识——同一文件两台同时猛改，任何同步工具都会疼。
• 你把同步目录当成唯一备份——同步不是备份，中了勒索或误删可能一起消失。

替代与局限

| 方案 | 我的体感 |

|------|----------|

| 商业网盘 | 分享链路强，大体积与长期成本要算账 |

| rsync/脚本 | 可控，但要自己做调度与失败恢复 |

| Samba/FTP | 像挂盘，不等于持续双向同步 |

| Syncthing | 设备间持续同步强，外部分享弱 |

局限也要说清：初次理解设备 ID、文件夹共享、忽略列表有学习成本；移动端体验和桌面不完全对等；网络环境差时要有心理预期。它强大，但不是「零配置魔法」。

我的工作流建议

1. 先同步「可再生成本高」的目录：素材、写稿、设计源文件；node_modules、构建产物坚决忽略。
2. 重要数据仍做版本备份：Git 管代码；时间点备份管文档与资源。
3. 冲突策略写清楚：哪台是主力机，尽量避免两台同时编辑同一办公文档。
4. 安全默认：设备引入要确认，局域网/中继按需开启，别图方便全开不明端口。

对做多产品线的人，同步策略属于基础设施。站点可以快速上线，文件乱了，人会先崩。

小结

Syncthing 帮我把「跨设备搬大文件」从临时动作变成背景能力。它不替代 Git，不替代网盘分享，更不替代备份；它替代的是我那些半吊子手工同步。独立开发者如果正在被多机文件折磨，值得认真试一次。