Syncthing 系列目录
- Syncthing 怎么用？从设备配对到文件同步的实用笔记
- 用 Docker 部署 Syncthing：Compose、端口和目录映射避坑
- Syncthing 多设备怎么配？对等网络、星型拓扑和引入者
- Android 上怎么用 Syncthing？Syncthing-Fork 配置与照片备份
- Syncthing 多设备多文件夹怎么管理？拓扑、命名和版本控制
- Syncthing 如何同步 iPhone 照片到电脑或 NAS
Syncthing 设备一多，文件夹一多，如果不提前规划，很快就会乱。
典型情况是：手机、平板、笔记本、台式机、NAS 都在同步；文件夹里又有照片、工作文档、代码项目、微信备份、电子书。每个设备都能改，每个目录都可能共享，最后你很难判断“这个文件到底从哪里来，又会同步到哪里去”。
要把 Syncthing 用稳，核心不是多装几个客户端，而是建立一套管理规则：
- 拓扑上用星型结构。
- 文件夹上统一 ID 和路径。
- 设备关系上使用引入者。
- 数据方向上区分备份和双向同步。
- 中心节点上开启版本控制。
- 临时文件用忽略规则过滤。
拓扑：放弃全连接，优先星型
Syncthing 是 P2P 对等架构，但不代表所有设备都要两两配对。
如果 5 台设备互相全连接，需要维护 10 组设备关系。新增一个文件夹时，还要在多台设备上接收、设置路径、确认共享。设备越多，管理成本越高。
更推荐的方式是星型拓扑。
选一台长期在线、空间大、网络稳定的设备作为中心节点：
- NAS
- 群晖
- 软路由
- 迷你主机
- 24 小时开机的电脑
其他设备只和中心节点配对：
|
|
手机不直接加笔记本，笔记本也不直接加台式机。手机要把照片同步给电脑，先同步到 NAS，再由 NAS 同步给电脑。
这样做的好处是：
- 新设备只需要和 NAS 配对。
- 文件夹关系集中在 NAS 上管理。
- NAS 可以统一做版本保留。
- 设备离线时，NAS 仍然能作为缓冲点。
缺点是 NAS 更重要了。它应该稳定运行，并且需要单独备份。
Folder ID 比文件夹标签更重要
在 Syncthing 中，真正识别一个同步文件夹的是 Folder ID，不是你看到的标签名。
标签只是显示名称，可以在不同设备上不一样。Folder ID 才是判断“这些设备上的文件夹属于同一个同步组”的关键。
所以，在第一台设备创建文件夹时，建议手动指定规范 ID。
例如：
|
|
不要使用随手生成的随机 ID，也不要只写 test、sync、new-folder 这类无法长期维护的名字。
命名规则可以简单一些：
- 双向同步：
notes-main、work-docs - 手机备份：
backup-pixel-photos、backup-iphone-photos - 资料分发：
media-ebooks、media-music - 代码目录：
code-projects
以后在其他设备接收共享时，只要看到 Folder ID，就能判断它是什么用途。
中心节点路径要规范
在 NAS 或中心电脑上，建议创建一个统一的 Syncthing 根目录。
例如：
|
|
不要把同步目录散落在系统各处。散落的目录短期方便，长期一定难维护。
推荐原则：
- 所有 Syncthing 管理的目录放在统一根目录下。
- 手机备份、工作文档、媒体资料分区存放。
- 文件夹名体现用途，不体现临时设备状态。
- 不把系统目录、下载缓存目录直接作为长期同步目录。
如果 Syncthing 跑在 Docker 中，还要注意容器内路径和宿主机路径的对应关系。
例如宿主机目录：
|
|
映射到容器内：
|
|
Web UI 里填写的是容器内路径，不是宿主机路径。
引入者：减少多设备配对成本
Syncthing 的 Introducer，中文界面通常叫“引入者”。
它适合星型拓扑。
做法是：把 NAS 设为引入者。之后新设备只要和 NAS 配对，NAS 就可以把已知设备和共享关系介绍给新设备，减少你在各个设备之间重复扫码、重复添加的工作。
适合：
- 家里有多台电脑和手机。
- NAS 是长期中心节点。
- 经常新增设备。
- 希望减少设备配对操作。
但不要乱用。
建议：
- 只把 NAS 或主服务器设为引入者。
- 普通手机、平板、临时电脑不要设为引入者。
- 新设备加入后，检查它被自动添加了哪些设备和文件夹。
- 不信任的设备不要进入引入者管理范围。
引入者能提高效率，也会扩大自动关联范围。它适合有清晰中心节点的网络，不适合混乱的临时设备环境。
区分备份和双向同步
多文件夹管理里，最重要的一件事是：不要所有目录都用 Send & Receive。
不同目录的数据方向不一样。
手机照片备份
手机端：
|
|
NAS 端：
|
|
这样手机负责发送照片，NAS 负责接收保存。手机清理空间、NAS 整理目录时，都不容易互相影响。
多端文档和笔记
电脑端：
|
|
NAS 端：
|
|
手机端是否加入双向同步，要看你是否真的在手机上编辑这些文件。如果手机只查看资料，可以考虑 Receive Only。
资料分发
NAS 端：
|
|
其他设备：
|
|
适合电子书、安装包、参考资料这类中心分发目录。
备份目录
主设备：
|
|
备份机：
|
|
再配合备份机端版本控制或快照。
NAS 上开启文件版本控制
多设备同步最怕误删和误覆盖。
例如：
- 某台电脑误删了工作文档。
- 手机清理工具删了相册目录。
- 两台设备同时改了同一份笔记。
- 某个同步规则写错，把空目录同步过去。
因此，中心节点最好开启文件版本控制。
在 NAS 的 Syncthing Web UI 中：
- 打开对应文件夹设置。
- 进入文件版本控制。
- 选择合适的版本策略。
常用选择是 Staggered File Versioning，也就是阶段版本控制。它会按时间间隔保留历史版本，越旧保留得越稀疏。
也可以用更简单的策略：
- Trash Can File Versioning：类似回收站。
- Simple File Versioning：保留固定数量版本。
- Staggered File Versioning：按时间阶段保留。
如果不知道选什么，普通家庭 NAS 可以先从 Trash Can 或 Staggered 开始。
版本控制不是完整备份，但它是多设备同步里的后悔药。
用忽略规则过滤临时文件
多设备同步代码项目、文档目录或聊天备份时，临时文件和缓存很容易制造麻烦。
常见问题：
- 占用大量带宽。
- 产生无意义冲突。
- 不同系统生成不同缓存文件。
- 删除目录时被忽略文件阻挡。
可以在文件夹设置的 Ignore Patterns 中添加规则。
通用临时文件：
|
|
Node / Python / Java 项目：
|
|
如果代码项目本身已经由 Git 管理，通常不建议用 Syncthing 同步 .git 目录。可以忽略：
|
|
(?d) 的意思是：如果整个目录准备被删除，Syncthing 可以删除这些本地生成的忽略文件，不会因为残留缓存而阻止目录删除。
忽略规则不要一次写太复杂。先覆盖最明显的缓存和临时文件，再根据实际冲突慢慢调整。
多文件夹命名示例
可以建立一套固定命名方式。
手机照片：
|
|
iPhone 照片：
|
|
主笔记库：
|
|
工作文档：
|
|
电子书：
|
|
只要 ID、标签、路径都有规律，多设备之后也不会失控。
推荐整体方案
如果你已经有 Docker 版 Syncthing 跑在 NAS 上，可以这样设计：
- NAS 作为中心节点。
- NAS 设为引入者。
- 所有设备只和 NAS 配对。
- 所有同步目录放在
/volume1/Syncthing/下面。 - 手机照片目录使用手机
Send Only、NASReceive Only。 - 工作文档和笔记使用
Send & Receive。 - 资料分发目录使用 NAS
Send Only、其他设备Receive Only。 - NAS 上对重要文件夹开启版本控制。
- 代码和缓存目录配置忽略规则。
- NAS 本身再做快照或异地备份。
这套结构建立起来后，再增加新设备或新文件夹，只需要按规则放进去，不需要每次重新思考同步关系。
总结
Syncthing 的自由度很高，但自由度越高，越需要规则。
多设备、多文件夹场景下，不建议做全连接网状同步。更稳的方式是让 NAS 或常开电脑做中心节点，统一 Folder ID、统一路径、统一版本控制，再用文件夹类型区分备份、双向同步和资料分发。
这样既保留了 Syncthing 的 P2P 能力，又把日常管理收束到一台中心设备上。设备再多，文件夹再多，也不会变成一团乱线。