Unison 介绍与选型指南

目标：说清 Unison 是什么、解决什么问题、与 rsync/Syncthing 等同类工具的本质差异，帮助读者判断「双向受控同步」场景下是否应选 Unison。本文信息全部溯源自官方渠道（GitHub 仓库、官方发布件内 NEWS/INSTALL/手册），溯源日期 2026-11-01；安装与配置的完整实测见本专栏后续篇章。

一、环境信息

本文是认知篇（介绍与选型），不依赖本地部署，关键事实的溯源渠道与查询日期如下：

• 项目仓库：https://github.com/bcpierce00/unison （查询日期 2026-11-01）
• 项目官网（UPenn 维护页）：https://www.cis.upenn.edu/~bcpierce/unison/ （查询日期 2026-11-01）
• 版本与发布节奏：官方发布件内 NEWS.md（随 v2.54.0 发布件分发，查询日期 2026-11-01）
• 社区活跃度：shields.io 实时徽章接口（GitHub stars / forks / license / last commit，查询日期 2026-11-01）
• 官方手册：Unison File Synchronizer User Manual（随 v2.54.0 官方二进制发布件分发，doc/unison-manual.pdf / .txt / .html，查询日期 2026-11-01）
• 构建与平台支持：官方发布件内 INSTALL.md（v2.54.0，查询日期 2026-11-01）

💡 说明：Unison 的官方手册不以独立网站为主要载体，而是随源码与发布件分发（也可通过 unison -doc topics 在命令行直接阅读内置手册），这一点在同类工具中比较少见，写作本文时以发布件内文档为权威依据。

二、软件概述

Unison 是一个双向文件同步器（bi-directional file synchronizer），由宾夕法尼亚大学（UPenn）Benjamin C. Pierce 团队开发并维护，使用 OCaml 语言编写，许可证为 GPL-3.0（license 信息经 shields.io GitHub license 徽章实查，查询日期 2026-11-01）。官方手册对它的定位是一句话：

Unison is a file-synchronization tool for POSIX-compliant systems (e.g. BSDs, GNU/Linux, macOS) and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.（出自 v2.54.0 官方手册 Overview 章节）

这句话里有三个关键词，理解了它们就理解了 Unison 的全部价值：

1. two replicas（两个副本）：Unison 的世界里只有「两份对等的目录副本」，没有服务端/客户端、主/从之分。两份副本可以分别位于两台主机（最常见的形态），也可以是同一台主机上的两个目录。
2. modified separately（各自独立修改）：两份副本可以同时被独立修改——这是 Unison 与 rsync 这类单向镜像工具的本质区别。rsync 的语义是「让目标无限趋近于源」，而 Unison 的语义是「把两边的变更互相传播，最终收敛到一致」。
3. propagating the changes in each replica to the other（互相传播变更）：一次同步会同时检查两侧的变更，无冲突的变更自动传播，冲突的变更停下来等人工决策——Unison 从不自动覆盖或删除你的数据。

💡 技术拓展：文件同步领域主要有三类同步模型，选型前先认清自己需要哪一类——

模型	代表工具	语义	冲突处理
单向镜像	rsync、cp	目标无限趋近源，源是唯一权威	无冲突概念，目标端同名文件会被覆盖
双向受控同步	Unison	两副本对等，变更互相传播	检测到冲突即停下，由人工决定方向，绝不静默覆盖
实时自动同步	Syncthing	多节点常驻组网，变更实时互相发现	产生 *.sync-conflict-* 副本文件，事后人工合并

本文的主角 Unison 属于「双向受控同步」：它比单向镜像多了对等语义，比实时同步多了人工确认环节，适合「知道自己在同步什么、要求变更可控可审」的场景。

版本与活跃度（实查 2026-11-01）：最新稳定版 2.54.0（2026-05-01 发布，GitHub Releases 页 redirects 实查 + 发布件 NEWS.md 标注 Released 2026-05-01）；GitHub stars 约 5.6k、forks 约 278（shields.io GitHub stars/forks 徽章实查）；仓库最近一次 master 提交在 2026 年 9 月（shields.io last-commit 徽章实查）。项目自 1998 年发布以来持续维护近三十年，是同步领域存活时间最长的开源实现之一。

近期版本节奏（出自发布件 NEWS.md，查询日期 2026-11-01）：

⚠️ 注意：版本节奏表里最值得警惕的是 2.54.0 的协议断代——2.54.0 无法与 2.51.x / 2.52.x 互通（官方 NEWS 原文 "Unison will no longer interoperate with versions before 2.52.0"）。实际使用中「本机新版 + 远端旧版」是最高频的翻车点，报错形态与解决方法在安装篇有完整实测实录。

三、核心架构

Unison 是一个用户态（user-level）对等程序，整体架构可以拆成四个部分（依据 v2.54.0 官方手册 Overview 与 Basic Concepts 章节，溯源日期 2026-11-01）：

1. 对等副本（replicas）与根（root）

一次同步由两个 root 定义，root 就是「某台主机上的某个目录」。root 的书写形态决定了远端连接方式：

• 本地目录：/srv/data
• ssh 远端目录：ssh://user@host//srv/data（双斜杠后是远端绝对路径）
• socket 远端目录：socket://host:port//srv/data（远端常驻 unison 监听进程）

2. 更新检测（update detection）

Unison 在 ~/.unison/ 下为每对 root 维护一份 archive 状态文件（文件名由 root 路径哈希生成，如 ar474816c9dfc3975f1790bdb11c1a1b11），记录上次同步完成时两侧的文件清单（路径、内容指纹、时间戳、属性等）。下一次同步时，Unison 将两侧当前状态与 archive 中的「上次同步态」三方比对，得出每条路径的变更结论：新增、修改、删除、无变化，或两侧同时变更（即冲突）。这种设计让 Unison 无需全量扫描网络传输即可感知变更，对慢速链路友好。

💡 技术拓展：更新检测的扫描开销由 fastcheck 参数控制。开启时（Linux 上默认）直接比较文件 mtime 与大小是否与 archive 记录一致来判断「有没有变」，几乎零开销；关闭时对每个文件重算内容指纹，慢但能兜住 mtime 异常的场景。该参数在配置篇有逐项实测。

3. 调和（reconciliation）与传播（propagation）

比对完成后进入调和阶段：每条变更按「方向是否明确」分流。方向明确的（仅一侧变更），Unison 给出推荐方向；两侧同时变更且内容不同的，标记为冲突（交互界面显示 <-?->）。用户确认后进入传播阶段，把选定的变更复制到对侧——传输采用类似 rsync 的压缩协议，只传大文件中变化的部分，对带宽友好（手册原文 "Transfers of small updates to large files are optimized using a compression protocol similar to rsync"）。

4. 失败韧健（resilience）

手册将这一点列为独立特性："Unison is resilient to failure. It is careful to leave the replicas and its own private structures in a sensible state at all times"——即便同步中途异常终止，副本与 archive 也保持一致状态；真正的故障形态是「锁文件残留」（进程被强杀时），会得到明确的报错提示与恢复指引，不会损坏数据。这一点在命令篇有实测排障实录。

连接通道：两台主机间的 Unison 通信只有两种形态——隧道在 ssh 上（默认 22 端口，复用系统 sshd，无需额外开端口），或远端常驻 unison -socket 监听进程（自选端口，明文协议，仅建议内网）。手册原文："communicating over either a direct socket link or tunneling over an encrypted ssh connection"。Unison 没有常驻服务端进程、没有 Web 界面、没有配置中心——它就是一个 CLI 命令，定时与自动化交给 cron/systemd timer 或 -repeat 参数完成。

四、功能特性

以下特性均出自官方手册与 NEWS（溯源日期 2026-11-01），并在本专栏后续篇章中逐项实测：

• 真正的双向同步：两副本可各自独立变更，一次同步把两侧变更分别传播到对侧；非冲突变更可自动传播，冲突变更显式停下等人工决策。
• 冲突可见且可控：交互界面逐项列出冲突（<-?->），可用单个按键指定方向（> 左到右、< 右到左）、按新旧取舍（] 取较新、[ 取较旧）、批量匹配同类冲突，或跳过本次/永久忽略。
• 丰富的属性同步：支持同步修改时间（times）、属主（owner）、属组（group）、权限位（perms），2.53.0 起支持扩展属性（xattr）与 ACL。
• 灵活的忽略规则：ignore/ignorenot 支持 Name、Suffix、Path、BelowPath、Regex 五种模式语法，可精确到「只同步某个子目录」「排除某类临时文件」。
• 两种远端通道：ssh 隧道（默认推荐，复用系统 sshd 与密钥体系）与 socket 直连（远端常驻监听，适合无 shell 权限或性能敏感的内网场景）。
• 定时与自动运行：-repeat N（每 N 秒循环同步）、-repeat watch（基于 inotify 的实时触发，Linux 上由 unison-fsmonitor 辅助程序实现），配合 -batch 可实现无人值守；也可交给 cron/systemd timer。
• 跨平台一致体验：官方为 Linux（x86_64/i386，另有静态链接版）、macOS（x86_64/arm64）、Windows（x86_64/i386）提供 CI 构建的二进制（见 v2.54.0 Releases 资产清单，查询日期 2026-11-01），典型场景如「Windows 笔记本 ↔ Unix 服务器」。
• 慢链路优化：类 rsync 压缩协议、只传变化块，手册明确 "It is careful with network bandwidth, and runs well over slow links"。
• 无权限要求：用户态程序，两台主机上都不需要 root 与内核模块（手册 Overview 原文 "there is no need to modify the kernel or to have superuser privileges on either host"）。

五、快速开始（最小可用示例）

以下是最小可用路径（命令形态出自官方手册 Running Unison / Tutorial 章节；完整参数与实测回显见本专栏安装篇与命令篇）。唯一硬性前提：两端的 Unison 版本必须一致（2.54.0 不能与 2.51.x 互通，见上文版本节奏表）。

第一步：两端安装同版本 Unison（选一条安装路径，详见安装篇）：

# Ubuntu 22.04 发行版仓库（版本较老，2.51.5，适合快速试用）
sudo apt install unison
# 或官方二进制（2.54.0，推荐，详见安装篇方案 B）
wget https://codeload.github.com/bcpierce00/unison/tar.gz/refs/tags/v2.54.0  # 源码

第二步：准备两端的同步目录（本机与远端各一个）：

mkdir -p /srv/data          # 本机
ssh user@remote 'mkdir -p /srv/data'   # 远端

第三步：先测连通性（-testserver 只测试两端能否握手，不动数据）：

unison /srv/data ssh://root@remote//srv/data -testserver

第四步：执行首次同步（-batch 全自动接受非冲突变更；交互模式下按 ? 可随时调出按键帮助）：

unison /srv/data ssh://root@remote//srv/data -batch

第五步：日常化。把上面这条命令写进 profile 文件 ~/.unison/mydata.prf（root、ignore、batch 等参数写入配置，详见配置篇），之后每次只需：

unison mydata          # 交互式同步
unison mydata -batch   # 无人值守，交给 cron

💡 说明：unison <profile名> 是日常最省心的入口——参数全部沉淀在 ~/.unison/<profile名>.prf 中，命令行本身保持极短。

六、适用场景与限制

典型适用场景（与官方手册特性一一对应）：

1. 工作区/代码目录在两台机器间的受控双向同步：笔记本与服务器都改了代码，rsync 会覆盖一边，Unison 逐项对账后互传；冲突文件停下来让你决策，绝不动手覆盖。
2. 低频定时同步而非实时：NAS 与异地备份点之间每小时/每日同步一次（cron + -batch），链路慢也无妨（类 rsync 压缩传输）。
3. 异构平台间同步：Linux 服务器 ↔ macOS 工作机 ↔ Windows 机器，官方 CI 为三大平台发布同版本二进制。
4. 需要属性严格一致的镜像对：times/owner/group/perms 全同步，适合网站目录、配置目录在两台服务器间保持一致。
5. 对「变更可控、可审计」有要求的场景：交互界面每一步都先展示再执行，confirmbigdel 默认拦截「整副本被删」这类危险操作。

明确不适合的场景与限制：

1. 需要实时自动同步：-repeat watch 虽然能做到秒级触发，但 Unison 的设计哲学是「受控」，海量小文件高频变更的实时场景，Syncthing 的常驻组网模型更合适。
2. 多节点（>2）同步拓扑：Unison 一次只同步一对 root，N 台机器同步需要维护 N-1 条两两配对的 profile 并保证调度错开；Syncthing 原生多节点组网完胜。
3. 两端版本必须一致：跨版本不通是硬约束（2.54.0 不通 2.52 以下），集群内滚动升级 Unison 需要同时换两端。
4. 无 Web UI、无常驻服务：纯 CLI 工具，没有管理界面与告警体系，监控靠日志与退出码，运维自动化需自行封装。
5. 冲突不会自动合并：Unison 不做内容级合并（文本三路合并需借助外部 merge 命令），冲突文件只能选边、跳过或人工合并。

七、同类选型对比

围绕「文件同步」这个命题，把三个最常被拿来对比的工具放到同一张表里。数据来源：各项目官方仓库/发布件（Unison 数据查询日期 2026-11-01；Syncthing 与 rsync 的星数与许可查询日期 2026-10-30，来源同为其 GitHub 仓库与 shields.io 徽章接口）：

💡 说明：表中 rsync 与 Syncthing 的星数、版本与许可引自 2026-10-30 的查询结果（本批次同组组件 git-annex 撰写时统一取证），Unison 一行为 2026-11-01 实查；三方对比的「关键差异」在于同步模型与冲突哲学——如果你说不清「谁覆盖谁」是不是问题，那多半还没被 rsync 覆盖过数据，可以先从 Unison 的交互界面建立「同步前先看账单」的习惯。

选型建议（如果…则…）：

• 如果是两台固定机器间低频双向同步（工作区、网站目录、配置目录），且希望每次同步前心里有数 → Unison。
• 如果是定时备份/发布，方向永远单一、目标端只做接收 → rsync（更轻、更快、生态无处不在）。
• 如果是多台设备实时互同步（笔记本/手机/NAS 常在线，追求无感） → Syncthing。
• 如果管理的是大量文件的价值分级与跨机搬运（哪些进仓库、哪些留在本地），属于数据管理而非目录同步 → git-annex 一类的内容寻址管理器。
• 如果两端版本无法保证一致（例如老系统上只有发行版仓库的 2.51.5）→ 两端都装 2.51.5 维持同版本线，或统一用官方二进制升级到 2.54.0，切勿混用。

八、参考链接

1. Unison 项目官网（UPenn）：https://www.cis.upenn.edu/~bcpierce/unison/
2. GitHub 仓库（bcpierce00/unison）：https://github.com/bcpierce00/unison
3. Releases 页（v2.54.0 与历史版本）：https://github.com/bcpierce00/unison/releases
4. Obtaining Unison Sources and Binaries（官方 Wiki）：https://github.com/bcpierce00/unison/wiki/Obtaining-Unison-Sources-and-Binaries
5. 官方手册随发布件分发：源码包 doc/unison-manual.pdf / .html / .txt，或命令行 unison -doc topics
6. 本文版本与发布日期信息：v2.54.0 发布件内 NEWS.md（Released 2026-05-01）
7. 本文构建要求信息：v2.54.0 发布件内 INSTALL.md（OCaml ≥ 4.08，make 构建）