文件同步工具对比：Syncthing、rclone、Google Drive 与版本冲突处理（横纵综合报告） 未开始

题记与说明

报告性质：横纵分析法综合报告（最终稿；按独立审读意见逐条修订自同日初稿，修订与口径处理见附录 A，开放问题见附录 B）。
输入材料：同日两份章节文件——《纵轴发展史》（parts/2026-11-04-文件同步工具对比-Syncthing-rclone-GoogleDrive-版本冲突-vertical.md）与《横轴对比》（parts/2026-11-04-文件同步工具对比-Syncthing-rclone-GoogleDrive-版本冲突处理-horizontal.md）。
时间截面：2026-11-04。
事实口径：全部关键事实来自两章当日会话内实际执行的网络检索与官方文档直接抓取（WebSearch / WebFetch / webReader），文中保留原始来源链接；个别无法核验处（如 Google 版本历史保留天数、rclone 的 MIT 许可）沿用章节的如实标注，不做臆测。两章之间的三处口径差异（Syncthing Android 停更时间、rclone v1.73.0 发布日、bisync 冲突命名的历史口径）已在附录 A 说明综合处理方式；本轮修订又对 Dropbox 冲突命名、Google 免费额度序列、Syncthing 1.x 收尾版本做了补充核验与口径统一，一并记入附录 A。修订中新增核验的来源集中列于参考来源 E 节（条目 23–28，均以 ★ 标注）。

TL;DR

三个主角代表三种同步哲学：Syncthing 是设备对等的去中心化网络，rclone 是存储间的中立管道，Google Drive 是云端为真相的中转盘。冲突处理呈三种范式：Syncthing 永不静默覆盖，落败副本改名 .sync-conflict-* 并全集群同步；rclone bisync 把裁决写成参数族，2025-08 转正；Google Drive 普通文件冲突生成副本，Docs 原生格式靠实时协同从源头消灭冲突。行业底线是先保两份、合并还人，没有主流工具做文本自动合并。选型：隐私实时选 Syncthing，上云搬运自动化选 rclone，文档协作选 Drive；成熟用户用三层组合，把冲突当流程问题。

结构指引：一、纵轴发展脉络；二、横轴对比；三、交叉洞察；四、决策建议与工程做法——全文最有行动价值的选型决策表、三层组合架构与工程做法集中于此章；附录 A 记录口径差异与修订处理；附录 B 为"开放问题与后续验证清单"，逐条回应：Syncthing 1.x/2.x 互通与升级步骤、Drive 版本历史保留期、国内可达性应对、bisync 最小可用命令、.sync-conflict 批量清理脚本、iOS 替代方案。

一、纵轴：发展脉络（1996–2026）

三个工具并非在同一年起跑，也不在同一条赛道上跑：Google Drive 是云服务（2012 年发布），rclone 是云间搬运工具（2012 年始），Syncthing 是去中心化同步（2013 年末）。纵轴回答的问题是：这条技术线从哪里来、被什么力量一次次改道，以及"版本冲突处理"如何从一个无人问津的边缘问题，变成 2020 年代各工具的显式一等特性。

阶段〇（1996–2011）：前史——冲突问题在同步范式的缝隙中诞生

• rsync（1996，Andrew Tridgell 与 Paul Mackerras）：以滚动校验和 delta 算法实现高效单向镜像。"sync"一词自此被定性为"把 B 变成 A 的副本"——单向模型里逻辑上不存在冲突，只会静默覆盖。这是后来一切冲突问题的"负片"。（Linux Journal：File Synchronization with Unison）
• Unison（约 2001，宾夕法尼亚大学 Benjamin C. Pierce 与 Jérôme Vouillon）：第一个把"双向同步 + 冲突检测"作为一等问题的严肃工具。它在两侧保留上次同步状态的档案，识别"两边都各自改过"的文件并标记为冲突、不自动应用任何一方——确立了"冲突必须显式交给用户"的学术范式。（Unison 官方站点、How to Build a File Synchronizer（Pierce & Vouillon））
• Dropbox（2008 上线）：把冲突处理从学术带入大众消费市场，固化了今天广为流传的惯例——同时编辑同一文件时自动生成 "conflicted copy" 副本，把编辑者用户名、"conflicted copy" 字样与保存日期加进文件名，两版都保留（官方原话："The editor's username, 'conflicted copy', and the save date will be added to the filename."）。官方页给出三种触发场景：两人同时编辑、有人离线编辑、文件在另一台设备上被应用自动保存；并明确"最后保存的版本总是成为冲突副本"。（Dropbox 官方支持：What's a conflicted copy?）
• Google Docs（2006 年借 Writely 收购起步）：为协作文档引入操作变换（OT）式实时合并，与"文件级副本"范式形成对照。2013-03-19 Google 发布 Drive Realtime API，把实时协同能力开放给第三方。（Google Developers Blog，转引自 Wikipedia: Google Drive）

驱动因素：个人多设备化、宽带普及、分布式系统理论成熟。此时"文件同步"与"协同编辑"是两个行业；冲突处理在文件同步一侧仍是无名之辈。

阶段一（2012–2013）：三条线在 18 个月内先后诞生

• Google Drive 上线即免费 5GB；2013-05-14 起 Gmail/Drive/Photos 统一为 15GB 免费额度（Wikipedia: Google Drive、Firstpost：Google unifies cloud storage across Drive, Gmail, Plus Photos to 15GB）。检索中曾见"1GB→2GB→2.8GB→7.5GB→10GB"的序列，经核对实为 Gmail 免费存储的历年沿革（2004 年 1GB 起步、2005 年 2GB、2012-04 随 Drive 发布同月 Gmail 升至 10GB），并非 Drive 的额度口径——初稿误植，已删去该序列，详见附录 A。
• rclone 的动机极有画面感：Nick Craig-Wood 受 rsync 启发，又嫌家庭服务器"吵且费电"，转投云存储，用 Go 语言从零写起；首个公开发布（v0.96）只有三个后端——Swift、Google Drive、S3。他与 rclone 的"十年"自述见 rclone 论坛：Rclone is 10 years old today；起源叙述见 Wikipedia: Rclone 与 rclone.com/about。
• Syncthing 的直接催化剂是 BitTorrent Sync 的闭源：社区明确喊出"BTSync 是闭源的，如果你介意……"（Reddit /r/linux 讨论、ghacks 2014-05-13 报道）。Jakob Borg 用 Go 写出了自带 TLS 加密、自研 Block Exchange Protocol 的 P2P 同步；2014 年 Steve Gibson 在 Security Now! 第 456 期公开背书其为"BitTorrent Sync 的开源替代"（Wikipedia: Syncthing）。

驱动因素：多设备与云存储成为刚需；Go 语言降低了跨平台单二进制工具的门槛；PRISM 事件让"端到端加密 + 自托管"从极客趣味变成正当需求。

阶段二（2014–2016）：各自成形，冲突处理第一次被"看见"

• rclone v1.00（2014-07-03）转正，此后进入"每季度一次大版本"的节奏（rclone 官方 changelog）。
• Syncthing 0.11（2015-04-22）——本课题的关键版本节点：首次内置冲突处理。两侧同时改动同一文件时，Syncthing 不做合并，而是把"败方"改名为 文件名.sync-conflict-<日期>-<时间>-<设备ID>.<扩展名> 保留，让用户自行取舍。（Wikipedia 版本表、Syncthing 官方文档：Understanding Synchronization）。随后 0.12（2015-11-05）引入中继与 HTTPS 设备发现，0.13（2016-05-17）与 0.14（2016-06-19）完成协议大版本更替。
• Google 侧的"无限存储"军备竞赛：2013-05 将 Gmail/Drive/Photos 免费额度统一为 15GB；2014-03 存储降价 80%（媒体直评"让 Dropbox、OneDrive 显得像抢钱"，Digital Trends，转引 Wikipedia）；2014-06-25 发布 Drive for Work（企业无限存储，$10/月）；2014-09-30 推出 Drive for Education（教育机构免费无限）。（均见 Wikipedia: Google Drive）
• 冲突处理格局就此定调：Dropbox 用"conflicted copy"命名保留双方（用户名 + "conflicted copy" + 日期，官方文档）；Syncthing 用 .sync-conflict-* 后缀保留双方；Google Drive 桌面端的行为则始终缺乏官方统一文档，第三方评测（digitalcitizen.life 的云同步冲突横评）与 IT 管理员的实际体感（Reddit r/sysadmin：Is Google Drive sync conflict resolution really this bad?、Reddit r/sysadmin：Drive for Desktop users: your proven anti-conflict playbook）都指向"复制出重复文件、行为不一致、不如 Dropbox 可预期"。这个"官方文档空白"本身就是贯穿至今的一条线索。

阶段三（2017–2020）：生态分流——桌面客户端分裂、rclone 出圈、滥用与污名

• Google 桌面客户端"一分为二再合一"的前半程：2017-03 面向企业推出 Drive File Stream（按需流式下载、映射盘符、支持 Shared Drives）；2017-07-12 面向个人推出 Backup and Sync（合并原 Drive 与 Photos 桌面应用）；旧 Drive 桌面应用 2017-12 停止支持、2018-03 停用。（Wikipedia: Google Drive、The Verge 2017-09-07）
• rclone 与"无限存储"的蜜月与破裂：Amazon Drive 曾以 £55/年无限存储著称，2017-05-23 起封禁 rclone 等上传工具的新用户（The Register，转引 Wikipedia）。此后 rclone 用户大规模迁往 Google Drive/G Suite 无限额度，"rclone + crypt 加密 + Plex 直接挂载网盘"成为一代亚文化。
• rclone 的关键版本：v1.35（2017-01-02）大幅增强 mount 可靠性、面向全部后端（v1.35 发布帖）。2020-03，Nick Craig-Wood 辞去自己创办的 Memset 公司职务，全职投入开源（Wikipedia）。同年 rclone 修复密码生成弱点 CVE-2020-28924（影响 1.49.0–1.53.2）。
• 共享 client ID 限流之痛：rclone 默认 OAuth client ID 为全体用户共享配额，Google Drive 侧频繁 403 rate limit exceeded，"自建 Google Cloud 项目 + 自己的 client ID"教程在 2020 年前后井喷（Level1Techs 2020-01 教程、rclone 论坛讨论）。
• 工具的污名：2020 年起 ProLock、Egregor、FiveHands 等勒索软件团伙用 rclone 把窃取数据外传到云端，FBI 连发多份通报（Wikipedia: Rclone 学术评价与安全事件节）。中性工具被滥用，是 rclone 知名度的另一种来源。
• 无限存储时代进入倒计时：2020-11-11 Google 宣布自 2021-06-01 起，Photos"高质量"上传与 Google 文档格式不再豁免配额（The Verge，转引 Wikipedia）。
• Syncthing 毕业：2019-01-01 发布 v1.0.0（"Erbium Earthworm"，论坛帖题为"Syncthing graduation day"），启用类 semver 规则（v1.0 公告）；2019-07 的 v1.2.0 引入 QUIC 传输；项目于 2019 年前后完成向 Syncthing Foundation 的资金与治理过渡（syncthing.net/foundation）。
• 值得一提的是，rclone 侧对双向同步的需求早在 2015 年就被提出（GitHub issue #118），但直到七年后才有官方实现——工具演进的优先级由用户呼声与维护者精力共同决定。

阶段四（2021–2023）：收敛、Bisync 与"丢文件"事故

• rclone 十年线上的 2021：v1.55（2021-03-31）引入 CERN/CS3MESH4EOSC 赞助的连接串等特性（v1.55 发布帖）。（初稿误列于阶段三，现移入本阶段。）
• Google 客户端"合二为一"完成：2021-07-12 发布 Google Drive for desktop，以 File Stream 代码为基础统一两类客户端；2021-10-01 Backup and Sync 停止支持。（Ars Technica 2021-07-12、Workspace Updates）
• Workspace 存储政策转折：2022-07 起教育版从"无限"改为 100TB 池化配额（Wikipedia: Google Drive），全球高校与依托"无限 G Suite"的 rclone 脚本农被迫迁移——这是 rclone 用户结构的一次大洗牌。
• bisync 之路（本课题冲突主题在 rclone 侧的主线，纵轴章节经逐条核实）：
  1. 前身是第三方脚本 rclonesync-V2（约 2017 年起使用）（rclone 论坛）；
  2. v1.58.0（2022-03-18） 正式以实验特性引入 rclone bisync（贡献者 localhuman）（v1.58 发布帖、rclone 官方 bisync 文档标注 "added in v1.58"）——检索中曾出现"v1.55 引入"的说法，经直接核对 v1.55 发布帖确认其未提及 bisync，故不采信；
  3. 2022-04 社区爆发"Bisync should be considered experimental"的警告与 GitHub issue #6082（出错时可能双侧删文件）；
  4. v1.63.0（2023-06-30） 由 nielash 完成大规模重写（rclone changelog）；
  5. v1.66.0（2024-03-10） 改用"快照模型"降低同步期间变更带来的风险，并引入冲突显式参数 --conflict-resolve（取值 none/newer/older/larger/smaller/path1/path2）与 --conflict-loser（num/pathname/delete）；v1.66 之前的默认行为是把冲突文件按来源侧改名为 ..path1/..path2 后缀（v1.66 发布帖、bisync 文档、GitHub issue #7471）；
  6. v1.71.0（2025-08-22） bisync 终于从 beta 转正为 stable（rclone changelog）。
• Syncthing 稳定演进：v1.20.0（2022-05-04）、v1.23.7（2023-07-31，最后官方支持 Windows 7 的版本）（Wikipedia 版本表）。2021-09 LWN 发表长篇好评，称其"可靠、安全、性能合理，而且易用"（LWN: Syncing all the things）。
• 云端即真相的脆弱性：2023-02 Google Drive 静默引入"500 万文件创建上限"，2023-04-03 被发现后因用户反弹一天内撤回（Engadget，转引 Wikipedia）；同年 Drive for desktop 爆出长达六个月的丢文件 bug，2023-12 修复（Forbes：Google Confirms 6 Months Of Missing Drive Files）。这类事故持续为"数据自主权"叙事供弹。

阶段五（2024–2026）：平台摩擦、代际更替与冲突处理的一等公民化

• 平台政策改写工具版图（Syncthing 侧最重事件）：2024-10-20 官方宣布停更 syncthing-android，直接原因是 Google Play 的 targetSdk 30+ 要求与"All Files Access"权限限制迫使应用改走 SAF，导致应用不可用；v1.28.0（2024-10-04）成为最后一个附带官方 Android 版的发布，停更于 2024 年底生效；社区接棒者是 Catfriend1 的 Syncthing-Fork（官方公告：Discontinuing syncthing-android、It's FOSS News 2024-10-23、syncthing-android 仓库）。
• Syncthing 2.0（2025-08-12）：1.x 常规系列终结于 v1.29.7（2025-06-02）（v1.29.7 公告），2025-07-01 官方补发 v1.30.0 作为旧平台（Windows 7 等 2.x 不再支持的系统）的最后驻留版（v1.30.0 公告、Windows 7 支持讨论；初稿记"1.x 终结于 v1.29.7"，系本轮核验后更正，见附录 A）；2.0 将数据库后端从 LevelDB 迁往 SQLite（首次启动需迁移）、引入结构化日志、以独立的 stable-v2 更新通道发布（官方公告、发行注记）；随后 2.0.5 等快速修边，当前稳定版 2.1.7（2026-10-21）（Wikipedia 版本表）。
• rclone 持续高频迭代：v1.69（2025-01-12）→ v1.70（2025-06-17，新增 convmv、VFS 元数据扩展）→ v1.71（2025-08-22，bisync 转正）→ v1.72（2025-11-21，发布帖）→ v1.73（2026-01 月底，新增 Filen/Shade/Drime/Internxt 后端）→ v1.74（2026-05，加入内嵌 Web GUI 与 iCloud Photos 后端）→ v1.75（2026-07-31，NFS 子路径挂载、SFTP 主机密钥固定），当前稳定版 1.75.2（2026-10-09），近期版本集中修复安全问题（rclone changelog、下载页）。商业侧成立 Rclone Services Ltd 提供付费支持，Nick Craig-Wood 仍为主开发者（rclone.com/about；本次检索未发现任何"换帅/退居二线"公告）。
• Google Drive 的当下：2024 年 Gemini 进驻 Drive 侧栏（The Verge 2024-05-14，转引 Wikipedia）；Chrome 应用 2025-07-15 停用；2026-05 启用新 logo；用户规模约 20 亿（2024-12 数据，转引 Wikipedia）。冲突处理的官方文档依然单薄——与 Dropbox 的专门支持页形成鲜明对比（Dropbox 官方冲突说明 vs 第三方代劳的 Filerev 指南）。
• 冲突处理范式终局盘点：

纵轴小结：五条驱动线索

回看十四年（2012–2026），这条曲线被五股力量反复改道：

1. 存储经济学：无限存储的发放（2014）→ 收敛（2017 Amazon 封禁、2021 Google 取消豁免、2022 教育版池化）直接制造了 rclone 的兴起与两次用户大迁徙。
2. 平台政策：Google Play 的 targetSdk/SAF 政策可以一夜停掉一个十年项目的官方客户端；Chrome 应用退役、logo 更迭则提醒我们，"云服务"侧的工具寿命从不由用户决定。
3. 安全事件：PRISM 催生了 Syncthing 的加密-by-design 与自托管浪潮；勒索软件对 rclone 的滥用（FBI 通报）则警示中性工具的双刃属性。
4. 技术底座：Go 语言让三个工具都以单二进制跨平台形态存在；FUSE/VFS、QUIC、SQLite、OT/快照模型分别是各自路线的台阶。
5. 社区与商业化：单人（calmh、ncw）→ 基金会/核心团队（Ivan Andreev、nielash、Catfriend1 等）→ 商业实体（Rclone Services Ltd）与 EU 赞助（CERN/CS3MESH4EOSC）三种路线并存。

而"版本冲突处理"的时间线本身，就是这条纵轴最浓缩的缩影：1996 年单向模型假装它不存在 → 2001 年 Unison 把它变成学术命题 → 2008 年 Dropbox 把它做成消费惯例 → 2015 年 Syncthing 0.11 把它写进协议 → 2024 年 rclone bisync 把它变成命令行参数。

二、横轴：横向对比（2026-11-04 截面）

2.1 参评对象与坐标定位

2.2 总对比表

2.3 架构与同步模型：三种世界观

Syncthing 的世界观是"设备网络"。 每台设备既是客户端也是服务器，数据只在设备间流动，没有中心节点。好处是隐私（数据不经第三方）、零存储费、局域网内全速；代价是要求两端同时在线才能完成同步、NAT 穿透在苛刻网络下需要中继（relay）、没有 iOS 官方客户端，且官方 Android 应用已于 2024 年停止维护，由社区 Fork（Syncthing-Fork）接续。

rclone 的世界观是"存储之间的管道"。 它不是常驻同步服务，而是一组命令：copy/sync/move/check/mount/bisync。它以 40+ 云厂商后端（rclone.org 官方口径；官方后端分层页把本地、SFTP、HTTP、WebDAV 等一并计入后达约 70 个）成为云存储事实上的统一 CLI。2026 年的新版本仍在快速演进：v1.73.0 新增 Internxt、Filen 等后端，v1.74.0 加入内嵌 Web GUI 与 iCloud Photos 后端，当前 v1.75.x 集中修复安全问题。

Google Drive 的世界观是"云端是真相之源"。 所有设备与云对齐，云端存储、搜索、分享、协作一体化。代价是数据托管在谷歌、免费空间仅 15GB，以及网络可达性问题（对国内用户裸连不稳——经验判断）。

2.4 版本冲突处理（核心维度，逐工具详述）

冲突的本质场景：同一文件在两个位置在"上一次同步完成之后"都被修改且内容不同。三个主角的处理策略代表了三种范式。

范式 A——Syncthing：永久保留 + 确定性命名（"不丢数据"）

以下内容来自官方文档《Understanding Synchronization》的直接抓取核验：

• 触发条件：两台设备同时修改同一文件且内容确实不同才产生冲突；若"修改 vs 删除"竞争中删除获胜，幸存的修改文件也会被标记为冲突副本。
• 裁决规则：修改时间（mtime）较旧的文件被标记为冲突文件；mtime 相同时，比较双方设备 ID（源自节点证书的定长指纹，按位看待的长二进制串）前 63 位的数值，数值较大一方的文件被标记为冲突副本（官方原文："the file originating from the device which has the larger value of the first 63 bits for its device ID will be marked as the conflicting file"）——固定的位级比较保证所有节点对"谁是冲突副本"得出一致结论。
• 命名与传播：落败副本改名 <文件名>.sync-conflict-<日期>-<时间>-<modifiedBy（落败版本的产生设备，表中简写为"设备"）>.<扩展名>，并且像普通文件一样被同步到集群所有设备，用户在任何节点都能看到全部版本。
• 边界：没有"一键解决冲突"按钮（官方论坛确认），需人工合并后删除冲突副本；社区有辅助脚本如 syncthing-resolve-conflicts（dschrempf/syncthing-resolve-conflicts，2017 年首发于论坛帖；更多清理方案见附录 B 问题 5）与 冲突机制讨论。

优点是零数据丢失、跨平台一致、可预测；缺点是把合并工作完整留给用户，对 Obsidian 这类"文件常被应用锁定"的场景，论坛/Reddit 有大量冲突堆积的抱怨（r/ObsidianMD：File conflicts in Syncthing、r/ObsidianMD：Syncing with Syncthing creates conflicts、Syncthing 论坛：Recurring sync-conflicts、syncthing issue #8604：MacOS + Android + Obsidian 冲突、Stephan Miller：Syncthing for Obsidian）。

范式 B——rclone：可编程的冲突策略（"规则判胜"）

以下内容来自官方《Bisync》文档的直接抓取核验：

• 冲突定义："双侧相对上一次运行都新增/修改，且当前两侧内容不一致"。若内容一致（哪怕都改过），不视为冲突。
• 默认行为（--conflict-resolve none）：不中止运行，保留两份并自动重命名——file.txt 变为 file.txt.conflict1 与 file.txt.conflict2，且两份互拷到对侧。
• 规则判胜：--conflict-resolve newer|older|larger|smaller|path1|path2 按修改时间/大小/指定侧定胜负；若对端缺属性或打平，自动回落到 none（不会硬判）。
• 落败方处置：--conflict-loser num（默认：自动编号，按时间顺序给落败副本追加下一个可用编号，file.txt.conflict1、conflict2……）/ pathname（按来源侧命名为 file.txt.path1/file.txt.path2，即 v1.66 之前的默认行为；官方明确警告：此模式没有 2 以上编号——若同一来源侧再次冲突，新落败副本将顶用同名而覆盖先前落败副本）/ delete（官方原话："inherently the most destructive option, so use it only with care"，即"本质上是最具破坏性的选项，务必谨慎"；若无法判出胜者，delete 会被忽略并回落为 num）。
• 命名定制：--conflict-suffix 支持逗号分隔给两侧不同后缀，并支持 {DateOnly} 等日期变量（命令参考）。
• 安全护栏：手册开篇即警告"未完整阅读手册就使用可能造成数据丢失"；--max-delete 默认 50%，配合"全量文件变化即中止"检查防误删；--resync 阶段另有独立的 --resync-mode。

对比 Syncthing，rclone 把"冲突怎么办"变成了显式、可脚本化的策略参数——适合想把裁决规则写进 cron 的工程师；代价是 bisync 属"高级命令"，配置错误的风险显著高于 Syncthing 的零配置路径。另外 rclone 的同步是按次执行的，实时性靠外部调度弥补。这条参数化路线从 v1.58 的实验特性走到 v1.71 转正花了三年半，中间经历一次重写和一次快照模型改造，与纵轴阶段的记录完全吻合。

范式 C——Google Drive：副本化 + 唯一的"源头协同"（"让冲突不发生"）

• 非 Google 格式（如 .xlsx/.md）：冲突时生成重复副本而非覆盖——两份文件都在，用户人工取舍（digitalcitizen 解析、社区帖）；这也是用户抱怨"(1) 副本堆积"的主要来源。
• Google 原生格式（Docs/Sheets/Slides）：编辑即保存、多人实时协同、完整修订历史——冲突在产生之前就被消灭。这是三个主角中唯一从数据模型层面解决冲突的方案（协同编辑思想，与 CRDT/OT 类系统同源——经验判断）。
• 版本历史：网页端右键"管理版本"可查看/下载/保留历史版本，官方支持页提供对特定版本"Keep forever"的标记（Check activity & file versions，检索确认；该页直接抓取超时未逐字核验）；即便冲突产生了重复副本，历史版本仍可追溯。保留期细节（网上常见说法为约 30 天或最多 100 个版本）为检索摘要口径、未逐字核验，故不给出确切天数——见附录 B 问题 2。

竞品对照（同范式一览）

（Dropbox 与 Nextcloud 的命名口径经本轮分别核对：Dropbox 官方只描述"用户名 + 'conflicted copy' + 保存日期"；"文件 (conflicted copy 日期).ext"式写法经核验为 Nextcloud 客户端行为，初稿曾误植到 Dropbox 行，已更正——见附录 A。）

横轴核心洞察：全行业没有任何一款主流同步工具做文本级"自动合并"（Office 文档的提示性合并除外）。大家收敛在同一底线——先保住两份数据，把合并还给人；区别只在命名规则、传播范围和策略可配置度。真正消除冲突的唯一主流路径是 Google Docs 式实时协同。

2.5 版本历史与快照

• Syncthing：按文件夹配置四种版本化——trashcan（删改件进 .stversions）、simple（保留 N 天）、staggered（按"近密远疏"节奏保留多版本，自动清理）、external（外挂脚本）（官方版本化文档）。配合冲突文件机制，可把"误删 + 冲突"双双兜底。
• rclone：无内建版本库，但 --backup-dir/--suffix 可把每次覆盖/删除的文件留存到时间戳目录，等价于"穷人版快照"；再叠加对象存储自身的版本化（如 S3 versioning）可走得更远。
• Google Drive：原生格式修订历史最强；上传型文件历史版本可在"管理版本"中查看/下载，并可对特定版本标记"Keep forever"（官方支持页功能，检索确认；保留期细节未逐字核验，见附录 B 问题 2）。
• 结论：Drive 对文档最强；Syncthing 的 staggered 版本化对个人文件库最省心；rclone 靠组合拳。

2.6 加密与隐私

• Syncthing：传输全程 TLS；对静态数据，持有文件夹密钥的节点均可见明文；"不可信设备"机制（v1.23+，文件夹加密密码）可让中转节点只存密文。
• rclone：rclone crypt 叠加层可对任意后端（含 Google Drive）做文件名+内容的端侧加密，配合 bisync 近似"零知识云同步"——这是它相对 Drive 的独特卖点。
• Google Drive：传输与静态均有加密，但密钥托管在谷歌，无端到端加密；隐私模型是"信任服务商"。
• 结论：隐私强度 Syncthing ≈ rclone（+crypt） > Drive；易用性相反。

2.7 生态与集成

rclone 以 40+ 云厂商、约 70 个后端成为云存储事实标准，被大量备份/自动化工具直接调用；Google Drive 背靠 Workspace 生态（文档协作、Gmail 附件、共享盘），移动端体验最佳；Syncthing 自成体系，生态体现在社区集成（Home Assistant、NAS 套件、Obsidian 用户社区等）。

2.8 成本

2.9 成熟度与社区健康度

• Syncthing：2013 年 12 月启动至今约 13 年，约 9 万 GitHub 星、5.6k fork（仓库直接核验），MPL-2.0。2025-08 的 2.0 完成 LevelDB→SQLite 的底层数据库换代——换代不动同步协议：2.0.0 发行注记明确 v2"brings a new database format and various cleanups, but remains protocol compatible with Syncthing 1"，维护者 calmh 在官方论坛补充"The database is device-local. Devices speak a database-agnostic protocol with each other."（Syncthing version 2 – interoperability with version 1、r/linux：Syncthing 2.0.0 released），即 1.x 与 2.x 设备可以混跑组网（互通细节与升级步骤见附录 B 问题 1）。这说明项目仍在做伤筋动骨的现代化而非养老式维护。风险点：官方 Android App 停更，移动端生态依赖社区 Fork。
• rclone：发版节奏极快（近一年 v1.72→v1.75.x），后端持续扩张，安全问题修复活跃；社区生态（论坛、第三方 GUI：rcloneUI、RcloneView、Bisync Hub 冲突工作台 等）繁荣。
• Google Drive：商业巨头，成熟度最高，迭代由产品战略驱动（当前重心明显向 AI 套餐倾斜）。
• Unison：UPenn 学术项目持续维护（仓库），适合作为"可靠双向同步"的保守选择。

2.10 性能与适用规模

• Syncthing：局域网表现好；大数据集首次扫描与索引较慢（官方论坛有从 Resilio 迁入者抱怨扫描时长：Moving from Resilio, the scan times are much longer）；大仓库 + 频繁小文件（如笔记库）是冲突高发区。
• rclone：吞吐取决于云厂商限流与并发参数（如 Proton Drive 社区帖专门调优 429 限流：bisync + systemd 针对性调优帖、Proton Drive too many requests）；--transfers/--checkers 可调，适合 TB 级搬运与备份。
• Google Drive：Drive for desktop 支持流式（streaming）与镜像（mirroring）模式，本地不占满盘也能访问云端（经验判断，官方常规能力）；受上传带宽与配额约束。
• Resilio Sync（参照）：厂商口径称企业配置下单服务器可跑 10Gbps+，商业版对大媒体文件团队更友好，但闭源收费（厂商自述对比）。

三、交叉洞察：两轴结合说明了什么

洞察一：三种范式对应三种哲学，冲突处理史是整个课题的缩影

把纵轴和横轴叠在一起看，会发现一个干净的对应关系：横轴上三种冲突范式，正是纵轴上三种起源哲学在"冲突"这一个点上的投影。

• Syncthing 起源于"对设备网络的信任"（数据只在设备间流动、谁也不许覆盖谁），所以它的冲突方案是"保留双方、全集群传播"——冲突副本本身也是网络的一员，任何节点都能看到全部版本。这套机制从 2015 年 0.11 引入后十一年未变，成为社区工具链（如 Obsidian 社区的 Conflict Resolver 插件）的对接标准。
• rclone 起源于"管道中立"（工具只是搬运工，不持有真相），所以它的冲突方案是把裁决权完全交给用户写进参数——--conflict-resolve newer/path1 之类，本质上是把 Unison 2001 年的学术范式（冲突显式交给用户）翻译成了 2024 年的命令行接口。
• Google Drive 起源于"云端是真相"，所以它对冲突的态度是两头都不管：普通文件靠副本化兜底且官方文档留白，而它真正的答案在 Docs 原生格式上——既然云端是唯一真相，就让所有人实时编辑同一份真相，冲突从源头不发生。

纵轴的最后一站（阶段五"一等公民化"）与此完全吻合：rclone 用参数把冲突写进命令行，Syncthing 靠十年稳定的命名惯例成为事实标准，Google Drive 则用自身在普通文件冲突上的留白，实证了"留白的代价"。两条轴共同说明：冲突处理不是某个工具的功能细节，而是同步哲学的试金石——三种哲学在同一个问题上给出了三种答案。

洞察二：行业从未解决"合并"，只解决了"不丢"与"不覆盖"

横轴的竞品对照表给出一个反直觉的事实：从 1996 到 2026，三十年间没有任何主流工具做文本级自动合并。纵轴解释了为什么——这条技术线上的每一次"进步"，都是在回避问题而非解决问题：rsync 单向模型假装冲突不存在；Dropbox/Syncthing/rclone bisync/OneDrive/Nextcloud/Seafile 全部收敛到"保留两份、改名标记、合并还人"的同一条底线；Google 独辟蹊径，用 OT 实时协同把冲突消灭在发生之前——但这只对 Docs 原生格式有效，对普通二进制文件同样回到副本化。

对用户的推论是明确的：不要指望任何同步工具替你合并文本冲突。真正的解决路径在同步工具之外——Git（文本的版本化合并）或协同编辑工具（冲突不发生）。把"同步"和"协同"当成两个行业（正如 1996–2011 年它们本来就是两个行业），分别选对工具，比在同步工具里寻找"冲突解决"功能更有效。

洞察三：横轴的技术优劣，随时被纵轴的外力重排

如果只看横轴，Syncthing 在隐私、成本、冲突透明度上全面占优，似乎"赢定了"。但纵轴记录了三次外力改道：

1. 存储经济学：2014 年无限存储的发放让"买云盘"比"搭 P2P"省心，2021–2022 年的收敛又把用户推回 Syncthing/rclone。横轴上的成本优势，价值随云厂商定价政策浮动。
2. 平台政策：2024-10 Google Play 的 targetSdk/SAF 要求一夜之间终结了 Syncthing 的官方 Android 客户端——这不是技术失败，而是生态位被平台方收回。同样的逻辑作用于 Google Drive 自身：Chrome 应用退役、免费政策收紧、客户端一分为二再合一，"云服务侧"的工具寿命从不由用户决定。
3. 安全事件：PRISM 催生了 Syncthing 的诞生土壤；勒索软件对 rclone 的滥用（FBI 通报）则说明，横轴上"中性工具"的名声会被纵轴事件改写。

两轴结合的结论：选型不能只看当前截面的参数表，还要看"这个工具的命运掌握在谁手里"。 Syncthing（基金会 + 社区）、rclone（单一核心维护者 + 商业实体 + EU 赞助）、Google Drive（单一公司产品战略）三种治理结构，面对平台摩擦的韧性完全不同——Google Drive 随时可被产品战略改写（当前重心已明显向 AI 套餐倾斜），Syncthing 的 Android 短板则要靠社区 Fork 补位。

洞察四：冲突处理的"可预期性"比"自动化程度"更重要

横轴对比自动化程度：rclone bisync 可编程 > Syncthing 固定规则 > Google Drive（普通文件）近乎随机。但纵轴显示，Google Drive 桌面端冲突行为"不够一致"的抱怨从 2014 年持续至今（digitalcitizen 横评、Reddit r/sysadmin：Is Google Drive sync conflict resolution really this bad?），而 Syncthing 那套"固定、简陋、不合并"的规则十一年零改动，反而成了用户可以放心构建工作流的基石——命名规则稳定到第三方插件可以直接解析 .sync-conflict-* 文件名（如 Obsidian 社区的 Conflict Resolver 插件与独立脚本 dschrempf/syncthing-resolve-conflicts）。

这印证了一个工程判断：对冲突处理而言，确定性和文档化比聪明和灵活更重要。 rclone bisync 的参数族虽然灵活，但 v1.58–v1.63 期间"出错可能双侧删文件"的历史（issue #6082）说明，灵活性有代价——事故之后 bisync 经历了 v1.63 重写与 v1.66 快照模型改造，当前文档把安全护栏（--max-delete 默认 50%、--resync 的显式确认要求）放在开篇反复警告；护栏与那段事故历史在时间线上紧随出现，先后关系可证，但并无材料表明二者是因果倒逼关系，故不作强断言。

（基于以上洞察的具体选型与工程做法，见下一章"四、决策建议与工程做法"。）

四、决策建议与工程做法

以下建议由第三章的洞察直接推出：先用三个变量定位场景，再用决策表给默认答案，然后用三层组合给架构，最后用四条工程做法把冲突变成流程问题。

4.1 选型三变量与决策表

选型三变量：数据敏感度（能否接受数据托管在谷歌）、并发编辑频率（是否多人/多机同时改同一文件）、云端依赖度（是否需要移动端随手访问与分享）。三个变量的取值组合直接映射到下面的决策表。

4.2 三层组合架构

三层组合架构（成熟用户的常态）：Syncthing 负责"设备间实时一致"→ rclone 负责把关键目录加密推到云端做异地容灾 → Google Drive 只承担"协作与分享"这个它最强的环节。三者互不替代——横轴的生态位分化正是纵轴十四年分流的结果。

4.3 冲突处理的四条工程做法

1. 让冲突可见且可检索：用 Syncthing 的 .sync-conflict-* 命名或 bisync 的 --conflict-suffix {DateOnly}，把冲突文件变成可 grep、可定期清理的对象，而不是散落的"(1)"副本。
2. 用版本化兜底：Syncthing 的 staggered 版本化、rclone 的 --backup-dir，保证任何误判都有回滚路径。
3. 对真正需要并发的文本，上 Git 或协同编辑工具，把"同步工具"从冲突一线撤下来——这是横轴竞品表与纵轴三十年的共同教训。
4. 设定理性预期：没有任何工具会替你合并文本；Google Drive 的 Docs 实时协同是唯一例外，条件是把工作内容搬进 Docs 格式。

4.4 补充判断

零知识云同步两条路：Syncthing 不可信设备（P2P 路径）与 rclone crypt（云存储路径）殊途同归，选哪个取决于你信任"对端设备"还是"云厂商的存储"。

成本套利：2TB Google One 约 $120/年；同容量用 Syncthing（自有盘）为 $0，用 rclone + B2 类对象存储通常更低但需自担运维——花钱买的本质是"托管、协作与移动端便利"。

维护性提醒：Android 用户需自行选择社区 Fork（Syncthing-Fork）并承担其维护连续性；rclone bisync 使用前必读手册（官方开篇即警告）；Google Drive 的冲突行为文档留白，重要文件建议避开"桌面端实时同步 + 频繁多机编辑"的组合，改用 Docs 格式或手动上传。

附录 A：口径差异与修订处理说明

A.1 两章差异的处理

本报告综合两份章节时，发现三处口径差异，处理如下：

1. Syncthing Android 停更时间：纵轴记"2024-10-20 官方宣布、v1.28.0（2024-10-04）为最后一个附带官方 Android 版的发布"；横轴两处记"2024-12 停更"。采用纵轴口径（有官方公告链接支撑），并补充"停更于 2024 年底生效"以兼容横轴表述——两者并不矛盾：宣布在 10 月，用户侧失效在年底。
2. rclone v1.73.0 发布日：纵轴记 2026-01-30，横轴记 2026-01-31，差一日（可能为时区/发布帖时间口径差异）。本报告统一记为"2026 年 1 月底"，不给出精确到日的日期。
3. bisync 冲突命名的历史口径：纵轴记录 v1.66 之前的默认行为为 ..path1/..path2 后缀（基于 changelog 与 issue #7471 的历史考证）；横轴记录现行文档的 .conflict1/.conflict2 默认命名（基于 2026-11 截面的官方文档直接抓取）。两者描述的是不同时间点，并非矛盾：本报告在纵轴部分保留历史考证，在横轴部分采用现行文档口径，并在 v1.66 的演进叙述中把两段衔接起来。

A.2 修订中的口径统一与更正（独立审读意见驱动，均经本轮补充核验）

1. Dropbox 冲突副本命名的统一：初稿第 24 行记 (Name's conflicted copy - 用户名 日期)，2.4 竞品对照表却记 文件 (conflicted copy 2024-05-15).ext（无用户名），同文档两种写法。经本轮直接核对 Dropbox 官方支持页（2025-05-15 更新版），官方只描述为"把编辑者用户名、'conflicted copy' 字样与保存日期加进文件名"（"The editor's username, 'conflicted copy', and the save date will be added to the filename."），未给出统一文件名模板；而"文件 (conflicted copy 日期 时间)"式写法经核验为 Nextcloud 客户端的行为（实证格式 filename (conflicted copy 2022-03-10 050117).ini，见 Nextcloud 论坛帖）。全文已统一为 Dropbox 官方描述口径，竞品表中 Nextcloud 行保留其自身格式；不存在"两种格式并存属实"的官方证据，故未写适用条件。
2. "免费额度沿革"序列的口径更正：初稿把"1GB→2GB→2.8GB→7.5GB→10GB→2013 年 15GB"序列归于 Google Drive，与"发布即免费 5GB"自相矛盾。经核对，该序列实为 Gmail 免费存储的历年沿革（2004-04 发布即 1GB、2005-04 升 2GB、2012-04 随 Drive 发布同月 Gmail 升至 10GB、2013-05-14 与 Drive/Photos 统一为 15GB；见 Firstpost 报道、Gmail 历史梳理），其中 2.8GB、7.5GB 两个中间值仅见"Gmail 存储计数器逐日增长"的轶闻描述、未获权威来源。已删去该序列，正文只保留两条已核验事实：Drive 发布免费 5GB、2013-05 统一 15GB。
3. Syncthing 1.x 收尾版本的补充核验：初稿记"1.x 系列终结于 v1.29.7（2025-06-02）"。本轮为回答"1.x/2.x 互通与升级"（附录 B 问题 1）而核验时，发现官方论坛存在 v1.30.0（2025-07-01）发布公告——1.x 常规系列止于 v1.29.7，v1.30.0 为面向旧平台（Windows 7 等 2.x 不再支持的系统）的收尾版。正文阶段五与 2.1 表已按此改写，以免与附录 B 的新表述冲突。

参考来源

A. 直接核验（两章当日 WebFetch 抓取原文；标注 ★ 者为本轮修订补充抓取核验）

1. Syncthing — Understanding Synchronization（冲突机制原文）：https://docs.syncthing.net/users/syncing.html ★
2. rclone — Bisync 文档（冲突定义与 --conflict-* 标志原文）：https://rclone.org/bisync/ ★
3. Syncthing GitHub 仓库（MPL-2.0、约 9 万星/5.6k fork）：https://github.com/syncthing/syncthing
4. rclone 官方 changelog：https://rclone.org/changelog/
5. Dropbox — What's a conflicted copy?（官方冲突命名描述）：https://help.dropbox.com/organize/conflicted-copy ★

B. 官方与项目方来源（检索佐证）

1. rclone 官网：https://rclone.org ；后端分层：https://rclone.org/tiers ；下载页：https://rclone.org/downloads ；bisync 命令参考：https://rclone.org/commands/rclone_bisync ；rclone.com/about：https://rclone.com/about
2. rclone 论坛发布帖：v1.35、v1.55、v1.58、v1.66、v1.72、十周年帖、bisync 风险讨论、Bisync Hub
3. GitHub：rclone/rclone issue #6082、#7471、#118（双向同步需求，2015）
4. Syncthing 官方：2.0 公告（发行注记）、版本 2 与版本 1 互通帖 ★、v1.30.0 公告 ★、升级澄清：1.x 不会自动升 2.x ★、Windows 7 支持讨论 ★、停更 Android 公告、v1.0 公告、v1.29.7 公告、基金会、版本化文档、冲突机制讨论、无 UI 解决按钮、syncthing-android 仓库
5. Google 官方：Workspace Updates（Drive for desktop 过渡）、Developers Blog（Realtime API）、Google One 计划与定价（美国口径）、Drive 冲突社区帖、Check activity & file versions（管理版本 / Keep forever） ★（检索确认存在，页面直抓超时未逐字核验）
6. 前史与竞品：Unison 官方站点、Pierce & Vouillon 论文、Linux Journal、Dropbox conflicted copy、Unison 仓库、OneDrive 同步排查（微软）、Seafile 冲突命名、Nextcloud 冲突处理 issue、Nextcloud 论坛：conflicted copy 命名实证 ★

C. 媒体与社区报道（检索佐证）

1. The Register：Amazon Drive bans rclone storage client
2. Forbes：Google Confirms 6 Months Of Missing Drive Files
3. Engadget：Google Drive 500 万文件上限
4. It's FOSS News：Syncthing Android 停更报道
5. Ars Technica：Drive for desktop 替代 Backup and Sync
6. The Verge：旧 Drive 桌面应用停用、The Verge：照片无限存储终结、The Verge：Gemini 进驻 Drive 侧栏
7. ghacks：Syncthing 早期报道、LWN：Syncing all the things、Digital Trends：存储降价 80%
8. digitalcitizen：云同步冲突横评、digitalcitizen：冲突副本解析、Filerev：Google Drive 冲突文件指南、overdrive.tools：Drive 重复文件、itGenius：Drive 冲突文件夹排查
9. Reddit /r/linux：Syncthing 诞生讨论、Reddit r/sysadmin：Is Google Drive sync conflict resolution really this bad? ★、Reddit r/sysadmin：Drive for Desktop anti-conflict playbook ★、Reddit r/sysadmin：缺乏冲突检测的应对 ★、Level1Techs：自建 OAuth client ID 教程、rclone 论坛：token 过期讨论
10. TrueNAS 文档：Syncthing/rclone 加密对照、Resilio 厂商自述对比、bluefoxconsultant：P2P 同步对比

D. 维基百科（经 webReader 全文读取）

1. Wikipedia: Syncthing / Wikipedia: Rclone / Wikipedia: Google Drive

E. 本轮修订补充核验的社区与第三方来源（2026-11-04 第二轮检索，标注 ★ 的链接为新增）

1. ★ Syncthing 互通与升级：Syncthing version 2 – interoperability with version 1（camlh："The database is device-local. Devices speak a database-agnostic protocol with each other."）、r/linux：Syncthing 2.0.0 released（发行注记引文 "remains protocol compatible with Syncthing 1"）、v1.30.0 公告、升级澄清帖
2. ★ Obsidian × Syncthing 冲突堆积：r/ObsidianMD：File conflicts in Syncthing、r/ObsidianMD：Syncing with Syncthing creates conflicts、Syncthing 论坛：Recurring sync-conflicts、syncthing issue #8604、Stephan Miller：Syncthing for Obsidian
3. ★ 第三方解析 .sync-conflict-* 的工具：Obsidian 社区插件 Conflict Resolver、dschrempf/syncthing-resolve-conflicts（2017 年论坛首发帖）、syncthing issue #9280：请求官方内置冲突解决
4. ★ 性能与限流社区帖：Syncthing 论坛：Moving from Resilio, the scan times are much longer、rclone 论坛：Automatic two-way Proton Drive sync（bisync + systemd，针对 429 调优）、rclone 论坛：Proton Drive too many requests、rclone issue #7413：ProtonDrive 大 API 用量
5. ★ iOS 替代方案：Möbius Sync 官网、App Store：Synctrain、GitHub：pixelspark/sushitrain（Synctrain 上游）
6. ★ 其他：Firstpost：Google 统一 15GB 免费额度、Gmail 历史梳理（存储沿革背景）

F. 未能核验事项：已并入附录 B.1（开放问题与后续验证清单的一部分）。

附录 B：开放问题与后续验证清单

（由初稿参考来源"E. 未能核验事项"扩展而来：B.1 保留并更新未核验事项，B.2 逐条回应读者必然追问的问题。）

B.1 未能核验事项（如实说明）

• 谷歌支持页（版本历史保留天数）多轮直接抓取均超时；官方"管理版本 / Keep forever"功能的存在经检索确认（支持页地址），但页面原文未逐字核验，本报告不给出确切保留天数。
• rclone 的 MIT 许可为社区共识（经验判断）；Syncthing 的 MPL-2.0 为仓库直接核验。
• Google One AI 套餐所含容量为检索摘要口径，订阅前请以官方页面为准。
• Resilio Sync 的 10Gbps+ 性能为厂商口径，未独立验证。
• Google Drive 对国内用户的可达性判断为经验判断，未做实测。
• rclone v1.73.0 的发布日在两章间有一日之差（01-30 vs 01-31），本报告取"2026 年 1 月底"。
• 本轮补入的社区帖链接（参考来源 23–28）证明了相关抱怨/调优行为的存在，但帖内观点属社区体感，非量化数据；iOS 客户端的实际体验未实测。

B.2 开放问题逐条回应

问题 1：Syncthing 1.x 与 2.x 能否互通？升级步骤是什么？（状态：已核验，来源为官方论坛与发行注记）

• 互通：可以混跑。2.0.0 发行注记明确 v2"brings a new database format and various cleanups, but remains protocol compatible with Syncthing 1"；维护者 calmh 在互通专帖解释："The database is device-local. Devices speak a database-agnostic protocol with each other."——数据库换代只发生在本机，设备间协议与数据库无关，故 1.x 与 2.x 设备可同网同步。2.0 公告另提及"Multiple connections are now used by default between v2 devices"（多连接默认仅作用于 v2 设备之间），不改变与 v1 的互通。极旧的 1.x 版本另受早期协议演进影响，混跑前建议各端至少升到 1.x 后期版本（经验判断，未逐版核验）。
• 升级步骤：① 1.x 不会自动升级到 2.x，需手动安装 2.x 安装包（官方升级澄清帖）；② 2.x 首次启动自动把 LevelDB 数据库迁移到 SQLite，发行注记原话"a migration on first launch which can be lengthy for larger setups"——大仓库请预留时间；③ Debian/Ubuntu APT 用户：2.x 放在独立的 stable-v2 组件中提供"软启动"，不会立即自动升级（2.0 公告）；④ 2.0 公告自述"first release of the new 2.0 series. Expect some rough edges"，且 2.0.1–2.0.7 陆续修了迁移与内存问题——建议先在单台设备验证再全群推进（经验判断）；⑤ 无法运行 2.x 的旧平台（如 Windows 7）停在 v1.30.0。

问题 2：Google Drive 版本历史保留多久？（状态：部分核验）

• 已核验：官方支持页提供"管理版本"与对特定上传版本的"Keep forever"标记（Check activity & file versions，检索确认存在；直抓超时未逐字核验）。
• 未核验：网上常见说法为"上传型文件旧版本约保留 30 天或最多 100 个版本，超期/超量版本会被清理，标记 Keep forever 的版本永久保留且计入配额"——此细节来自检索摘要而非页面直抓，不作结论，仅作后续验证线索。后续验证路径：换网络环境或镜像源直抓 support.google.com/drive/answer/2409045，并与 Workspace 管理员文档交叉核对。

问题 3：国内可达性有什么应对？（状态：经验判断，未实测）

• 基线事实（经验判断）：Drive 裸连不稳；Syncthing 纯 P2P 在可达网络内不受影响，但公网中继（relay）连接质量参差。
• 常见应对（均为经验判断，本报告不提供任何规避网络管控的具体工具指引）：① 优先自托管/端到端路线——Syncthing（可自建中继/引入节点）或 rclone 落到自选可达后端（自建 S3/WebDAV/国内可达对象存储）；② 确需 Drive 时，把它当"协作与分享层"而非主干存储，主干数据留在本地 + 自控备份；③ 对 bisync/crypt 类自动化，先小范围试跑验证网络稳定性再扩量。

问题 4：rclone bisync 最小可用命令示例？（状态：已核验，取自官方 Bisync 文档）

# 首次运行：建立基线。官方建议先 --dry-run 预演，确认输出无异常后再正式执行
rclone bisync /本地/工作目录 远程名:远程目录 --resync --dry-run
rclone bisync /本地/工作目录 远程名:远程目录 --resync

# 之后的日常运行：务必去掉 --resync
# （官方原话："For successive sync runs, leave off the --resync flag. (Important!)"）
rclone bisync /本地/工作目录 远程名:远程目录

• 护栏说明：--max-delete 默认 50%，超过即中止不落盘；首次 --resync 属"选边"操作，前务必读官方手册（Bisync 文档，含 --resync-mode 与更多参数）。官方 getting-started 示例还带 --create-empty-src-dirs --compare size,modtime,checksum 等参数，可按需加回。
• 冲突策略按需追加：--conflict-resolve newer（或 none/newer/older/larger/smaller/path1/path2）与 --conflict-loser num/pathname/delete（详见 2.4 范式 B）。

问题 5：.sync-conflict-* 批量清理脚本哪里找？（状态：链接已核验，脚本行为未实测）

• dschrempf/syncthing-resolve-conflicts：Bash 脚本，扫描 .sync-conflict 文件并辅助逐个解决，2017 年首发于官方论坛帖（受 Arch pacdiff 启发）。
• Obsidian 用户可用社区插件 Conflict Resolver：自动查找 .sync-conflict 副本并引导安全合并。
• 官方至今未内置一键解决（社区在 issue #9280 持续请求），因此删除任何冲突副本前请先人工比对内容——脚本只帮你"找到"和"改名"，合并判断仍在你。

问题 6：Syncthing 在 iOS 上怎么办？（状态：检索核验，未实测）

• 无官方客户端，且 iOS 沙盒机制决定了任何第三方应用都只能做受限的后台同步（社区共识，经验判断）。
• 现存第三方方案：Synctrain（免费、原生 Swift，上游 pixelspark/sushitrain，支持选择性同步与按需流式取文件，为 2025–2026 社区主流推荐）、Möbius Sync（老牌第三方，订阅/买断）、Sync Anything（较新，可同步相册）；早年的独立实现 fsync 已停更。追求稳定后台同步的场景，社区常见替代是改用 Resilio Sync 或 Nextcloud 客户端（经验判断）。