升级到 2.0 后首次启动变慢：数据库迁移与删除保留期

为什么升级后第一次启动特别久

v2.0 是近年最大的一次架构变更，官方发布说明里列的首要变化：索引数据库从 LevelDB 整体切换为 SQLite。首次以 v2 启动时会执行一次数据库迁移——官方明确说明「对较大的配置可能耗时较长」。

这是一次性的：迁移完成后，新数据库的日常表现与可维护性都比旧库好（官方的原话是更容易理解与维护，希望能少些 bug）。官方论坛的升级帖也确认：旧数据库的备份会被留在原地以备恢复。给大库用户的一句话：升级安排在睡前或工作间隙，让它慢慢跑完。

第二个行为变化：删除记忆的保留期

v2.0 的另一项官方列明的变化：已删除条目不再永久保留在数据库里，默认 15 个月后被遗忘。含义是：一台设备离线超过 15 个月再回来，集群已经不记得它错过的删除操作。官方同步给了配置入口（条目起始时间可调），有超长离线周期设备的用户需要留意这一项。

混合版本能不能共存

可以。官方论坛确认 v1 与 v2 设备可以混合组网——协议层兼容，不必所有设备同时升级。但注意：迁移只发生在「首次以 v2 启动」的那台设备上，且界面客户端（各类 GUI 封装）要确认兼容 v2 再更新。

Windows 忽略规则的一个连带变化

v2.0 起 Windows 上的 .stignore 转义字符改为竖线 |（反斜杠在 Windows 是路径分隔符）；想沿用反斜杠写法在文件首行加 #escape=\，跨平台通用规则写法见[前缀与 include(../05-控制同步内容/03-ignore-prefixes.md)。从 v1 升级后规则行为不对时先查这里。

升级路径小结

• 先备份的是数据本身（同步目录），数据库迁移失败也有旧库备份兜底；
• 逐台升级而非全集群同时动——混合版本是官方支持的状态；
• 升级后首次启动期间别拔电源，让它把迁移跑完；
• 其余升级方式（自动升级检查的开关与来源）属配置项，见[配置文件与密钥都在哪(../09-配置与进阶/01-config-files.md)。