Syncthing v2.1.6开源同步工具：去中心化多设备实时同步部署

资源概览

Syncthing 是一款开源的持续文件同步工具，定位与「网盘同步盘」相似，但实现路径完全不同：它没有中心服务器，没有账号体系，两台设备之间直接建立加密连接交换数据。

授权协议说明：MPL-2.0 属于宽松型开源许可，允许自由使用、修改、再分发与商业使用。它与 MIT 的差别主要在于「文件级 copyleft」——如果你修改了 Syncthing 自身的源文件并对外分发，这些被修改的文件需要以 MPL 发布；但把它集成进你自己的产品、与自有代码组合同一个程序，自有部分不受传染。这个特性是它被大量商业设备（尤其是各类 NAS 系统）内置采用的原因。

工作方式的要点：所有同步流量走设备间直连的加密通道。发现机制上，Syncthing 默认使用公共发现服务器来帮助设备找到彼此的地址；当两端无法直连（例如都在 NAT 之后）时，默认会借助公共中继服务器转发。这两条是理解其数据边界的核心——发现服务器只转地址信息，中继服务器会承载加密后的流量，如果不接受任何第三方参与，可以关闭发现与中继、改为手动指定地址，做到完全内网闭环。

核心功能亮点

一、设备 ID 配对，无账号体系。 每台设备启动后生成唯一的设备 ID（一串由公钥推导出的长字符串）。添加设备时把对方的 ID 复制过来即可，不需要注册、不需要手机号、不需要邮箱。这意味着一台设备可以彻底脱离任何厂商账号而存在。

二、持续双向同步。 与「一次性传输」工具不同，Syncthing 的工作模式是把某个目录标记为共享，此后任意一台设备上的增删改会自动同步到其他设备。适合需要长期保持多端一致的场景，例如笔记库、代码片段库、素材库。

三、细粒度的同步方向控制。 每个共享文件夹可以独立设置为双向、仅发送、仅接收。「仅发送」模式非常适合做备份目标分发——比如把主机的资料单向推给一台只作存储的机器，避免在备份机上的误删反向传播。

四、多档版本控制策略。 支持 Simple File Versioning（按数量保留历史版本）、Staggered File Versioning（按时间区间保留，时间越近的版本保留越密）、External File Versioning（调用自定义脚本处理旧版本）。误删与误覆盖是同步类工具最常见的灾难，版本控制是唯一能兜住这类事故的机制。

五、忽略模式。 通过 .stignore 文件声明不需要同步的模式，例如编译产物、日志、临时文件、.git 目录。支持 ! 反向排除语法，可以写出「忽略这个目录但保留其中某个文件」这类规则。

六、Web 管理界面与 REST API。 默认在 127.0.0.1:8384 提供图形界面，所有配置项都能在界面上完成。同一套能力也通过 REST API 暴露，配合 API Key 可以做自动化——这是它在无人值守场景（NAS、服务器）里被广泛使用的基础。

七、文件夹监视与按需扫描。 开启文件系统监视后，目录内发生变化会立即触发同步，无需等待周期性全盘扫描。大目录下这一项对资源占用与响应速度的影响非常明显。

八、传输加密与完整性校验。 设备间连接使用 TLS，数据块带有哈希校验。传输过程不依赖第三方信任，即使经由中继转发，中继方也只能看到加密后的内容。

适用场景

场景一：多台自有设备之间保持目录一致。 台式机、笔记本、家里的小主机上各有一份同一目录，任何一台上的改动其他几台自动跟上。不需要把私有资料放进第三方网盘。

场景二：把 NAS 或旧电脑变成私有同步中心。 一台长期在线的低功耗设备作为「中枢」，其余设备都与它同步，即使其他设备不同时在线也不影响最终一致性。这是「自建私有云盘」性价比最高的做法——不需要公网 IP，不需要域名。

场景三：手机照片自动回传到自有存储。 Android 版可以直接把相机目录设为仅发送，照片拍完自动推到主机或 NAS，全程不经过任何云端。

场景四：跨机备份。 用仅发送模式把重要目录持续推送到另一台机器或另一个磁盘位置，兼作异机备份。配合版本控制，删除操作也有挽回余地。

场景五：跨网络的文件分发。 给团队几台机器分发资料包，把目录共享出去，各自加入即可，后续更新自动下发，比反复传压缩包省事。

不适用的情况：需要一次性快速搬走几十 GB 的大文件（那是传输工具的活，同步工具会做索引与校验，开销更大）；需要多人协同编辑同一个文档（它做的是文件级同步，不做内容级合并）；需要细到列级别的权限管控（它只有文件夹级别的读写控制，没有企业级权限体系）。

下载与安装

官方下载地址：

• 官方发布页：https://github.com/syncthing/syncthing/releases

• 官网下载入口：https://syncthing.net/downloads/

Windows 安装步骤：

1. 下载 syncthing-windows-amd64-v2.1.6.zip（约 11.4 MB）。Windows 版官方提供的是压缩包，不含安装程序，解压即用。

2. 解压到固定目录，例如 C:\Tools\syncthing，双击其中的 syncthing.exe 启动。

3. 启动后会自动打开浏览器界面（默认地址 http://127.0.0.1:8384）。若未自动打开，手动访问该地址。

4. Windows 防火墙会提示网络访问，需要允许「专用网络」访问，否则同一局域网内其他设备无法直连。

5. 为了开机自启，可以把启动脚本放入启动项，或使用第三方工具注册为系统服务。注意：Syncthing 本身不自带 Windows 服务封装，注册服务需要额外工具。

Linux 安装方式：

多数发行版仓库中已有该包，可直接安装；也可下载官方 tar 包手动部署：

# Debian / Ubuntusudo apt install syncthing# 手动部署压缩包tar -xzf syncthing-linux-amd64-v2.1.6.tar.gzcd syncthing-linux-amd64-v2.1.6
./syncthing

以 systemd 用户服务方式常驻，可避免需要 root 权限：

systemctl --user enable --now syncthing.service
systemctl --user status syncthing.service

macOS 与 Android：

macOS 可下载官方压缩包，或通过 Homebrew 安装（brew install syncthing）。Android 版通过 F-Droid 等开源应用渠道获取，Android 版本对省电策略较敏感，通常需要在系统设置里为本应用关闭电池优化，否则息屏后同步可能停滞。

NAS 与容器：

常见品牌的 NAS 应用商店多数已内置；Docker 部署可使用官方镜像，把配置目录与待同步目录挂载为卷即可。挂载时建议保持 host 网络模式以简化端口映射。

快速上手

第一步，在两台设备上分别启动 Syncthing。 打开各自的 Web 界面，在「操作」菜单里找到「显示设备 ID」，记录或复制这串字符。

第二步，互相添加设备。 在 A 设备的界面上点「添加远程设备」，粘贴 B 的设备 ID，命名后保存。B 端界面会弹出「新设备想要连接」的提示，需要点击接受。 这一步是双向确认，单方面添加不会建立连接。

第三步，共享文件夹。 在 A 设备上找到要同步的文件夹，点「共享」勾选 B 设备；B 端会收到「设备想要共享文件夹」的提示，指定本地存放路径后接受。

第四步，等待初次索引与同步。 首次同步需要扫描并传输全部文件，耗时取决于数量与体积。状态栏显示「Up to Date」即表示同步完成。

第五步，按需开启版本控制。 在文件夹设置中把「文件版本控制」改为 Simple，保留份数填 5 或 10。这一步建议在共享的时候就做，事后补开对已经发生的覆盖没有追溯作用。

第六步，配置忽略规则。在文件夹内创建 .stignore 文件，写入不需要同步的模式；也可以直接在界面里维护。规则修改后需要触发一次重新扫描。

几个实用细节：把「文件夹监视」打开可以省掉周期全盘扫描的开销；中继与发现服务器如果不想使用，在设置里关闭后改用「地址列表」手动填写对端 IP 和端口（格式形如 tcp://192.168.1.10:22000）；同步目录不要选在会被其他程序频繁改写的路径下，否则会产生大量索引更新与冲突。

同类资源对比

选择的判断依据：「让几台设备上的目录长期保持一致」用 Syncthing；「按计划把 A 变成 B 的镜像」用 rsync；「不想折腾配置、能接受闭源」可以考虑 Resilio Sync；「只是临时把文件传过去」用 LocalSend。 它们解决的问题层次不同——Syncthing 与 rsync 是「保持状态」，LocalSend 是「搬一次东西」。

注意事项

授权协议： MPL-2.0。可自由使用、修改与再分发，包括商业用途。修改 Syncthing 自身源文件后对外分发时，被修改的文件需以 MPL 开源；自有代码与它组合使用时不受影响。本资源为开源软件，非破解版、非修改版，来源为官方发布页，代码可审计。

系统要求： Windows 10 及以上、主流 Linux 发行版、macOS、Android 常见版本均在支持范围。AMD64、ARM64 等架构均有对应构建，下载时注意选对架构。32 位系统请选择对应架构包，装错架构会直接无法启动。

网络安全建议：
- 理解数据边界：默认配置下设备会向公共发现服务器查询地址，直连失败时可能经由公共中继转发。转发内容是加密的，但流量确实经过了第三方主机。对数据流向有严格要求的场景，应关闭「全局发现」与「中继」，改用静态地址手动指定对端。
- Web 管理界面默认只监听本机。 如果为了远程管理把它改为监听所有网卡，必须同时设置用户名与密码，并尽量配合 HTTPS，否则同网段任何人都能访问你的配置界面。
- API Key 等同于账号密码。 通过 REST API 做自动化时，密钥要像密码一样保管，不要写进会被提交到代码仓库的文件。
- 防火墙端口：核心同步端口默认 TCP/UDP 22000，另外还需要 UDP 21027 用于本地发现。企业网络部署前先确认策略是否放行，否则设备只能靠中继通信。

已知限制：
- 文件级同步，不做内容合并。 两端同时修改同一个文本文件会产生冲突副本，需要人工比对。协同编辑场景不要用它，那是版本控制系统的职责。
- 两端同时在线才能实时同步。 离线设备上的改动要等到它重新上线才会上传，不会经过服务器缓存。
- 大目录首次索引消耗明显。 数十万文件的目录初次扫描会占用较多 CPU 与内存，建议先建好忽略规则再添加共享。
- 不提供权限体系。 共享出去就是读写权限（或只读），没有逐用户授权，不适合做多租户文件服务。
- 移动端受系统省电策略影响。 Android 上息屏后同步可能被挂起，需要手动调整电池优化白名单。

校验提示： 本资源已按官方发布的大小核对（11,980,853 字节）。下载后如大小不符，说明传输不完整或非官方渠道，建议从官方发布页重新下载，并核对发布页提供的校验值。