同步不是备份，误删也会被同步。

\n
Syncthing 在 HomeLab 里很容易被误解成备份工具。它真正擅长的是让几台可信设备之间保持文件一致：桌面机写文档，笔记本继续改，服务器保留一份在线副本。这个能力很实用，但它也会忠实同步删除、覆盖和错误修改。部署之前先把同步、备份、归档三件事分开，后面排查冲突时才不会把责任全推给软件。

设备 ID 要当资产记录

Syncthing 的信任关系靠设备 ID 建立。重装系统、重建容器、迁移配置目录之后，设备 ID 可能变化；旧设备条目留在其他节点上，新设备又被当成陌生成员，这时同步目录看着存在，实际却不会交换数据。我会把每台设备的名称、设备 ID、用途和共享目录写在同一份维护表里，例如 nas-main 负责长期在线，macbook 负责日常编辑，mini-pc 只接收某个目录。

设备名称不要写成随手起的昵称。半年后看到 node-1、node-2，基本无法判断哪台已经下线。更稳的写法是地点加角色，例如 study-desktop、nas-sync、laptop-work。新增设备时先只共享一个测试目录，确认版本、权限、忽略规则都符合预期，再开放正式目录。

单向和双向不要混着猜

很多同步事故来自“以为只是接收，实际双方都能写”。Syncthing 可以把目录设为发送和接收、仅发送、仅接收。桌面工作目录如果多台机器都会修改，可以用双向；手机照片导入、扫描件归档这类流程，更适合一端发送、一端接收。只接收端发现本地被改动时会标记为本地变更，不会悄悄替你决定谁覆盖谁，这一点比单纯共享目录安全。

真正上线前，我会给每个目录写一句话：谁能写，谁只读，冲突由谁处理。比如 documents 允许桌面和笔记本双向；inbox-scan 只允许扫描设备发送，服务器接收；archive 只允许服务器发送给备用设备。规则写清楚，比事后从日志里猜“到底哪边先改”省心很多。

冲突文件要定期处理

两台设备离线修改同一个文件后，Syncthing 通常会保留冲突副本。文件名里带有设备和时间信息，看起来有点乱，但这是保护数据的最后一道提醒。不要用清理脚本一把删掉所有冲突文件，尤其是文档、表格、配置这类小文件。更好的做法是每周用文件名搜索冲突副本，人工比对后合并或归档。

如果某个目录经常出现冲突，说明目录职责没有设计好。要么多人同时编辑同一批文件，要么某个程序会在后台改元数据。遇到这种情况，我会先缩小同步范围，把临时文件、缓存、编辑器状态目录加入忽略规则，再重新观察。Syncthing 适合同步真实成果文件，不适合同步随时变化的运行态目录。

版本控制是兜底，不是保险箱

Syncthing 的文件版本控制值得打开，尤其是文档、脚本、家庭资料这类体积不大但误删代价高的目录。简单版本控制可以保留最近几个旧版本，分层版本控制适合更长期的回退需求。目录很大时要控制保留数量和清理周期，否则版本目录本身会慢慢吃掉磁盘。

我不会把版本控制当作正式备份。它通常仍在同一台机器或同一套存储里，无法应对磁盘损坏、误格式化、勒索软件或整机丢失。正式备份应独立运行，有自己的保留策略和恢复演练。Syncthing 负责“多端一致”，备份负责“某个时间点还能回去”，两者不能混用。

Docker 部署时看三个目录

容器化部署时，配置目录、同步目录、版本目录要分清。配置目录保存设备证书和数据库，丢了就等于设备身份变了；同步目录保存业务文件，权限要和宿主机用户对齐；版本目录如果单独指定，也要纳入容量监控。挂载时我更愿意写绝对路径，并用只服务于 Syncthing 的系统用户运行，避免其他容器顺手写进同步目录。

排障顺序也固定：先看 Web 页面里设备是否已连接，再看共享目录是否完成扫描，然后看日志里有没有权限、路径、文件被占用的错误。最后再到宿主机检查 id、ls -ln 和目录剩余空间。同步工具最怕“看起来都在线”，实际某个目录因为权限失败一直停在待处理状态。

我会保留的维护记录

一套稳定的 Syncthing 记录至少包含设备 ID、目录 ID、同步方向、忽略规则、版本策略和备份关系。新增目录时先跑测试样本，删除目录时先暂停共享，迁移设备时先复制配置目录再确认 ID 是否保持不变。只要这些信息在，未来换机器、换硬盘或重装容器时，就能判断自己是在恢复旧节点，还是在接入一个全新节点。

我还会把“不要同步什么”写得很明确。比如构建产物、编辑器临时文件、浏览器缓存、应用数据库实时文件，都不适合同步。同步列表越克制，冲突越少，设备上线离线时的扫描压力也越小。