Syncthing 是一个单文件运行的同步守护进程：两台或更多电脑各跑一份，用设备 ID 互相授权，文件在设备之间直连传输，不经过第三方网盘。2.x 把索引库换成 SQLite，重写了命令行与日志格式。下面按 Windows 桌面场景走一遍安装方式、端口放行和资源占用控制。
它是什么，2.x 版本线改了什么
每个 Syncthing 实例都有一张设备 ID，是一长串 base32 字符。两台设备互相添加这张 ID 后建立信任关系，之后共享的文件夹才会开始同步。传输使用 TLS 加密，数据不落到中间服务器上。
2025 年 8 月发布的 2.0 是这条版本线的分界。索引数据库从 LevelDB 换成 SQLite，首次启动需要迁移旧库，数据量大的机器上耗时可能相当长。命令行解析也做了现代化改造，旧的单横线长参数不再被接受，例如 -home 必须写成 --home。这些改动在项目的 2.0 发布公告里逐条列过。
迁移期的内存峰值在 2.0.6 被压下来，此前清理动作是在内存中完成整库重写。2.0.7 又针对文件夹数量多的场景降低了常驻内存。开源中国在 2025 年 9 月也报道过 2.0.10 的发布，这期间基本保持每两周一个补丁版本的节奏。
2.1 系列的改动偏实用：设备和文件夹可以按 group 属性在界面里分组；代理除 SOCKS 外开始支持 HTTP 与 HTTPS 的 CONNECT；单个文件夹可以关掉块索引，用更大的传输量换更小的数据库；Web 界面的登录会话有效期也能改。细节见2.1.0 发布帖。
平台与安装包怎么选
官方发布页当前给出的是 v2.1.7。Windows 有 amd64、arm64 和 386 三种构建；macOS 提供通用包与两个架构的单独包；Linux 覆盖 amd64、arm64、386、arm，另外还有 loong64、riscv64、mips64、ppc64le、s390x 等少见的架构。FreeBSD、OpenBSD、NetBSD 与 illumos 也在列表里。
官方基础包就是压缩包，解压后直接运行，项目本身不提供安装程序。想要托盘图标、开机自启这类系统集成，可以换社区封装：Windows 用 Syncthing Windows Setup 或 SyncTrayzor v2，macOS 用 syncthing-macos。
Linux 发行版仓库里的版本常常落后一两个小版本。要跟新版就加 apt.syncthing.net 源，2.x 放在 stable-v2 组件下，这样可以自己决定哪台机器先迁移，不至于一次升级把在用的机器全都带进数据库迁移。
Windows：便携运行，还是装成服务
基础包解压后双击可执行文件，浏览器打开 127.0.0.1:8384 就是管理界面。进程退出同步就停，适合临时在别人机器上用，或者只想偶尔同步一次的场景。
Syncthing Windows Setup 提供两种安装模式。仅给当前用户安装时，它随用户登录启动；加上 /allusers 参数则为所有用户安装，会注册成 Windows 服务，早于登录就开始运行，适合当汇聚点的那台常开机器。
服务模式不用 LocalSystem 账户，而是专用的 SyncthingServiceAcct，这是只给必要权限的做法。装完之后要给同步目录授权，例如执行 icacls "D:Sync" /grant "SyncthingServiceAcct:(OI)(CI)M" /t，不授权会直接报权限错误。为所有用户安装时，安装器还会自动添加一条放行入站连接的防火墙规则。Helge Klein 的部署笔记里记录了这两处容易漏掉的细节。
Linux 侧对应的是 systemd 用户服务，想让服务在注销后继续跑，还需要执行 loginctl enable-linger，一份可照抄的写法见这篇安装记录。
端口、发现与防火墙
同步流量走 22000/TCP 和 22000/UDP，后者承载 QUIC 连接；21027/UDP 用于 IPv4 广播和 IPv6 组播的设备发现。如果改过监听地址，防火墙规则要跟着改，官方防火墙文档把这三个端口的用途写得很清楚。
管理界面默认只监听 127.0.0.1:8384。要远程看界面，可以改成 0.0.0.0:8384 并加上账号密码，也可以用 ssh -L 9999:localhost:8384 打隧道，后者不必把管理端口暴露出去。
Linux 上有现成预设：ufw 用 ufw allow syncthing，firewalld 用 firewall-cmd --zone=public --add-service=syncthing --permanent 后重载。想换掉 8384 也可以在界面里改，改完记得同步调整反向代理或隧道里的端口映射。
直连打不通时，连接会落到中继服务器上，能同步但速度差一截。只在局域网内使用就把中转、NAT 穿透和全局发现一起关掉，连接范围会被限制在本网段，代价是跨网段时要手写对端 IP。
资源占用：内存和 CPU 花在哪里
缓冲类参数直接决定峰值。收发的并发缓冲由 maxConcurrentIncomingRequestKiB 控制，这是一个全局上限，默认 262144 KiB，也就是 256 MiB；单文件夹的读请求缓冲 pullerMaxPendingKiB 默认 32768 KiB；同时进行的写入系统调用默认 16 个。这三个默认值在官方调优文档里都有对照表，同一页还给了低资源机器的建议值。
| 参数 | 默认值 | 低配建议 | 影响 |
|---|---|---|---|
| maxConcurrentIncomingRequestKiB | 262144 KiB | 32768 KiB | 全局收发缓冲总量 |
| pullerMaxPendingKiB | 32768 KiB | 16384 KiB | 单文件夹未完成读取请求 |
| maxFolderConcurrency | 随核心数 | 1 | 同时同步的文件夹数量 |
| copiers 与 hashers | 1 到核心数 | 1 | 复制与校验并发 |
| numConnections | 3 | 1 | 每台设备的连接数 |
文件系统监视也有成本。Linux 上每个 inotify 监视点约占 1080 字节，社区给出的经验值是 100 万个监视点大约要 1 GB 内存，官方论坛的相关讨论里有过完整推算。目录树很大时要先抬高 fs.inotify.max_user_watches，否则日志里会出现监视句柄启动失败的提示，然后退回定期全量扫描。
Go 运行时还认两个环境变量：GOMEMLIMIT 给垃圾回收一个软上限，GOMAXPROCS 压低可用的并行线程数。它们不写在配置文件里，要放进服务定义或 systemd 单元的环境变量段才生效。默认以较低进程优先级运行，把 setLowPriority 改成 false 可以换取一点吞吐，代价是前台变卡。
索引库建议放在固态盘上。首次迁移和版本升级后可能触发的整库重写都要反复读写它，机械盘上这段时间会明显拖慢整机；2.0 早期版本在迁移时还出现过把内存吃满、被系统杀进程的情况，社区里用 1 GB 内存的小机器复现过多次。
适用场景与上手顺序
比较合适的情形：两三台自己的电脑互相同步文档与素材；一台常开的小主机当汇聚点；局域网内搬运大文件；把手机相册定期收回本地。
不太合适的情形
- 需要多人评论、修订历史的文档协作，这类需求该用协同编辑工具。
- 只有一台设备，没有同步对象。
- iOS 上只想要官方客户端，iOS 侧目前由第三方 Möbius Sync 提供。
- 设备经常关机或长期离线，同步会一直排队。
它也代替不了备份。同步会把删除动作一起带到其他设备，误删只能靠文件夹的版本化功能兜底；长期归档可以对照站内自建备份工具清单里的思路另做一层。
上手顺序
- 装包，先进界面设置账号密码，别让 8384 裸奔。
- 两台设备互加设备 ID，一端发起、另一端确认。
- 建文件夹时保持文件夹 ID 一致，路径可以不同。
- 按用途选类型：双向同步、仅发送、仅接收。
- 补忽略规则与分层版本化，再回头调高级参数。
多机并用的场景里，键鼠共享和文件同步常常一起上，站内Deskflow 键鼠共享上手讲的是前一半。如果目标是让自托管相册读同一份目录，站内Immich 3.3.5 上手里的外部库思路可以和本机的仅接收模式对照着配。
三个常见问题
同步盘要留多大空间？数据库体积随文件数量增长，和文件总大小关系不大；预留几百 MB 到数 GB 都属正常，主要看索引到多少文件。
能不能只同步一个子目录？可以。把同步路径指到子目录即可，父目录里的其他内容不会进来；反过来想排除个别文件，用忽略规则比拆文件夹省事。
两端文件名大小写不同会怎样？Windows 盘默认大小写不敏感，跨到 Linux 时可能出现两个同名文件。介意这一点就在文件夹高级设置里打开大小写敏感选项，或者统一命名规则。
© 版权声明
文章版权归作者所有，转载需注明出处。未声明原创的皆为网络收集，如有侵权请邮箱lishiwenhuagx@sina.com联系下架处理。
相关文章
