1. 先弄清楚 Zotero 到底把东西藏在哪

先把一个最常见的误区挑明：很多人以为 Zotero 就是一个装在Program Files里的软件，卸载重装就完事。真到了重装系统、换电脑那天才发现，装回去的是一个空库，几百篇文献、上千个 PDF 附件、一堆手写笔记全没了。原因很简单，软件本体和数据是分开放的，而且分得比大多数人想的更彻底。Zotero 的文献库本质上是一个文件夹，不是一个云账号，只要这个文件夹完整地搬过去，你的库就一点都不少；反过来，只要这个文件夹掉了，装一百遍软件也找不回来。

这套手动无损迁移方法，适合三类人：一是准备重装系统、已经把 C 盘格了或者马上要格的；二是之前嫌麻烦直接把旧版本连数据一起删了、现在想从备份盘里把库捞回来的；三是换新电脑、不打算为官方同步空间付费、也不想折腾第三方同步盘的。方法本身不复杂，一台机器上做过一遍，后面基本闭着眼睛都能完成，难点全在几个细节上：哪些文件夹必须搬、搬完之后怎么让新装的 Zotero 认这个库、以及怎么确认真的一个字节都没丢。下面我按自己实际操作的顺序拆开讲，参数、路径、校验命令都给到位，你照着抄就行。

1.1 数据目录和配置目录是两个完全不同的东西

这是整篇文章最核心的一个认知，搞清楚这一条，后面 90% 的困惑都会自动消失。

**数据目录（Data Directory）**装的是"你的东西"：文献条目、分类、标签、笔记、附件 PDF、自定义引文样式。默认位置在用户主目录下的一个叫Zotero的文件夹里，三个系统分别是：

这个目录里面的核心成员只有几个，认准它们就不会搬错：

• zotero.sqlite：主数据库，所有条目、元数据、笔记、分类关系、标签全在这个 SQLite 文件里。
• zotero.sqlite.bak：软件自动生成的上一版备份，某些关键操作或版本升级前会刷新。它经常是救命稻草，别随手删。
• storage/：附件仓库。每个条目一个子文件夹，文件夹名是一串随机字符（Zotero 的 item key），里面躺着 PDF、图片、网页快照。
• styles/：你自己加进去的 CSL 引文样式。原版没几个，加了投稿期刊格式的人这里会有东西。
• translators/：自定义的网页抓取翻译器，用得少，但有就得搬。

**配置目录（Profile Directory）**装的是"软件的习惯"：界面语言、快捷键、已安装的插件、面板布局、同步设置。它和数据目录不在一个地方：

里面的prefs.js是纯文本，用记事本就能打开看；extensions/里是插件。配置目录不是必须搬的，但建议一起搬，尤其是你插件装得多、快捷键改过一堆的情况，搬过去省掉半小时重新配置。代价是插件版本可能和新装的 Zotero 版本不匹配，所以我的做法是：配置目录先复制一份留着，但迁移时只挑prefs.js里的自定义数据目录那一行手工改，插件到新环境再一个个装。这样做慢一点，但绝对不会出现"新版本被旧插件卡在启动界面"的尴尬。

注意：zotero.sqlite里不存附件文件本身，只存附件的相对路径和 item key。所以只拷数据库不拷storage/，打开后你会看到一长串灰色条目，点哪个都提示文件找不到。

1.2 为什么"手动搬文件夹"比官方同步更靠谱

有人会问，Zotero 自带同步，为什么还要手动搬？这个问题值得说清楚，因为它决定了你该选哪条路。

官方同步分两块：元数据同步免费，附件同步收费。也就是说，如果你的库里有几百个 PDF，想靠官方同步做到"换电脑后附件也在"，就得买存储空间。这不是坑，是成本结构，但对于一个自用、库又比较大的用户来说，手动搬一次文件夹的成本几乎为零，而且速度快得多，几百 MB 到几个 GB 的库，机械硬盘拷贝也就十几分钟。

手动迁移真正的优势有三点。第一是完整性，文件夹级拷贝是原样复制，不会有任何字段在同步协议里被丢掉，比如某些插件写入的自定义字段。第二是可回滚，拷贝之前先做一份冷备份，出任何问题原样退回去，同步方案做不到这一点。第三是不依赖网络和账号状态，换电脑、换系统、甚至换一个完全离线的环境，都不影响。

代价也很明确：手动迁移是一次性的，不是持续的。搬完之后两台机器上的库就各自独立了，后面新增的文献不会自动过去。所以我的实际做法是"手动迁移打底 + 免费元数据同步兜底"：先用文件夹整体搬过去保证一次到位，再登录同一个账号做元数据同步，之后两台机器的条目列表大致保持一致，附件各存各的。这个组合我用下来最省心，也不会因为某台机器忘了同步就丢东西。

2. 迁移之前必须做好的三件准备

跳过准备工作直接开拷，是出事概率最高的操作。我踩过的坑里，一半以上都不是拷贝过程本身出错，而是拷贝的时候数据库还在被写、或者备份只做了一份放在同一块盘上。下面这三件事，加起来花不了十分钟，但能把风险压到接近于零。

2.1 彻底关闭 Zotero 并确认没有残留进程

这一条听上去像废话，实际上是最容易翻车的地方。Zotero 在运行时会持有zotero.sqlite的句柄，同时目录下可能出现zotero.sqlite-journal这类临时文件。你这时候拷走的数据库，可能是一个"写了一半"的状态，拷过去打开就是损坏或者数据缺失。

正确做法是：先在 Zotero 里点菜单正常退出，不要直接关窗口（有些系统上关窗口只是最小化到托盘）。然后验证进程是否真的没了。

Windows 下打开任务管理器，看"详细信息"里有没有zotero.exe；或者用命令行：

tasklist | findstr /i zotero

macOS 和 Linux：

ps aux | grep -i zotero | grep -v grep

输出为空才算干净。如果还有残留，Windows 下用taskkill /IM zotero.exe /F强制结束，macOS 用killall Zotero。

结束之后再去数据目录看一眼，正常情况下应该只剩下zotero.sqlite、zotero.sqlite.bak、storage、styles这几样。如果看到zotero.sqlite-journal或者zotero.sqlite-wal，说明上次退出不干净，先把这两个临时文件一起拷走，让 SQLite 在下次打开时自行回滚，反而比手工删掉更安全。

提示：如果你是在系统已经崩了、根本开不了机的情况下抢救数据，把硬盘拆下来接别的机器或者用引导盘挂载，同样先找zotero.sqlite-journal，一并拷出来。

2.2 做一份"双份冷备份"，而不是一份

备份只做一份，等于没做。这句话在数据恢复圈子里是共识，我自己也栽过：唯一的一份备份放在移动硬盘上，结果那块盘在拷贝过程中掉盘，分区表直接乱了。

我的做法是同源双份 + 异地一份，具体来说：

1. 把整个数据目录复制到一个不同物理磁盘上，比如系统盘是 C，就复制到 D 盘或者移动硬盘。这是第一份。
2. 再复制一份到另一个位置，比如另一块移动硬盘、或者家里的网络存储。这是第二份。
3. 如果库不大（几百 MB 以内），再压缩成一个 zip 丢到网盘。这是第三份，也是最后一道保险。

复制的时候用能保留时间戳和权限的工具，不要用那种"拖拽复制"遇到同名文件就跳过的方式。Windows 下我习惯用robocopy：

robocopy "C:\Users\<用户名>\Zotero" "D:\Backup\Zotero_20250101" /E /COPY:DAT /R:1 /W:1 /LOG:D:\backup_log.txt

/E表示包含空目录，/COPY:DAT保留数据、属性和时间戳，/R:1 /W:1表示失败只重试一次、等一秒，避免卡在一个坏文件上死循环。日志文件留着，后面校验的时候能对得上。

macOS 和 Linux 用rsync更稳，-a归档模式保留一切属性，-H保留硬链接（Zotero 的 storage 里偶尔会有）：

rsync -aH --info=progress2 ~/Zotero/ /Volumes/Backup/Zotero_20250101/

备份完成后不要急着删原目录。整篇文章的所有操作，都是在"原目录还在、备份也在"的前提下做的，确认新环境完全跑通了再清理旧数据。

2.3 记录版本号、数据目录实际路径和库的规模

这个步骤很多人嫌麻烦跳过，但它决定了你出问题时能不能快速定位。需要记录三样东西：

第一，Zotero 的版本号。在"帮助 → 关于"里能看到，比如7.0.x。这个信息的用处在于：数据库 schema 是单向升级的，用高版本打开过之后，低版本就打不开了。如果你不确定新机器上装哪个版本，就装不低于旧机器的版本。

**第二，数据目录的真实路径。**如果你以前改过自定义数据目录（在"编辑 → 设置 → 高级 → 文件和文件夹"里），那默认路径就是空的，真正的库在别处。这种情况下直接去设置界面复制那行路径，别凭印象猜。

**第三，库的规模。**记下条目数量和storage文件夹的大小、文件数量。方法很简单：

# Linux / macOS 统计文件数 find ~/Zotero -type f | wc -l # 查看总大小 du -sh ~/Zotero

Windows 下用 PowerShell：

(Get-ChildItem -Path "C:\Users\<用户名>\Zotero" -Recurse -File).Count (Get-ChildItem -Path "C:\Users\<用户名>\Zotero" -Recurse -File | Measure-Object -Property Length -Sum).Sum / 1GB

把这两个数字记在记事本上。它们就是你后面校验的基准线，新环境里对不上，就说明有文件没搬全。

3. 手动无损迁移的完整操作流程

准备工作做完，真正的迁移其实只有四步：新机器先装软件但别急着开库、把整个数据目录整体搬过去、让 Zotero 指向这个目录、最后做三项硬校验。每一步都有具体的动作和明确的判定标准，我按顺序写，你按顺序做。

3.1 新机器先装软件，但第一次启动要"空跑"

这一步的顺序很关键：先装 Zotero，让它正常启动一次，然后再关掉，最后才放入数据。

为什么要多这么一步？因为新安装的 Zotero 第一次启动时会自动创建默认数据目录、初始化数据库、生成配置文件。如果你先把旧数据目录拷进去再启动，程序有可能判定"目录结构异常"，或者在初始化流程里覆盖掉某些文件。先空跑一次，把"骨架"建好，再把"血肉"替换进去，是最稳的顺序。

具体操作：

1. 到官网下载对应系统的安装包，装上。版本选不低于旧机器记录的那个。
2. 双击启动，看到主界面后，如果弹出"欢迎使用"或者同步设置向导，直接关掉，不要登录账号、不要开启同步。
3. 完全退出（同样用任务管理器确认进程已结束）。
4. 打开文件管理器，找到新建的默认数据目录，确认里面已经生成了zotero.sqlite和storage文件夹。

到这一步，新环境的骨架就有了。接下来的动作是"用旧的替换新的"，而在替换之前，有件事一定要做：把新生成的这个空数据目录整个改名留档，比如把Zotero改成Zotero_blank。这样万一后面发现搬错了库，你还有一个干净可用的默认环境可以退回去，不用重装。

3.2 把整个数据目录一次性搬过去

搬运的原则只有一条：搬"整个目录"，不要只搬数据库。我见过太多人只拷了zotero.sqlite过去，打开后条目全在、附件全灰，然后一脸茫然。

正确的搬运对象是数据目录下的全部内容，包括隐藏文件和子文件夹。如果你的目标位置就是默认路径（比如新电脑上同样是C:\Users\<用户名>\Zotero），那么直接把整个文件夹复制到对应位置，覆盖掉那个空目录即可。

如果目标位置不是默认路径（比如你想放到 D 盘，避免以后重装系统又得搬一次），那就复制到目标位置，比如D:\Data\Zotero。

这里有个实操细节值得强调：跨文件系统复制时，注意文件数量极多带来的性能问题。storage/下面是每个条目一个文件夹，几千条文献就是几千个子目录、上万个小文件。这种情况下用资源管理器拖拽，速度慢还容易在中途报错，强烈建议用命令行工具：

# Windows：把整个目录搬到 D 盘，保留所有属性 robocopy "E:\Backup\Zotero_20250101" "D:\Data\Zotero" /E /COPY:DAT /DCOPY:T /R:1 /W:1 /MT:8

/MT:8是开 8 个线程并行复制，小文件多的时候提速非常明显；/DCOPY:T保证目录的时间戳也保留。

# macOS / Linux rsync -aH --info=progress2 /Volumes/Backup/Zotero_20250101/ /Volumes/Data/Zotero/

注意rsync源路径结尾的那个斜杠，有斜杠表示"拷贝目录里的内容"，没斜杠表示"拷贝目录本身"，两者结果差一层，别写错。

3.3 用自定义数据目录接管，两种做法选一种

数据搬到位了，接下来要让 Zotero 知道"库在这儿"。有两种做法，区别在于你是否愿意改设置。

**做法一：放回默认路径，什么都不用设。**如果你把数据目录放回了默认位置（Windows 的C:\Users\<用户名>\Zotero），直接启动 Zotero，它会自动认。这是最省事的路径，适合不打算折腾的人。缺点是以后重装系统还得再来一遍。

**做法二：放在自定义路径，通过设置里改数据目录。**这是我推荐的做法，库放 D 盘或者独立数据盘，系统怎么重装都不影响。步骤是：

1. 启动 Zotero，进入"编辑 → 设置"（macOS 是"Zotero → 设置"）。
2. 切到"高级"标签页，找到"文件和文件夹"。
3. 点"自定义"按钮，选择你刚才放数据的那个目录（比如D:\Data\Zotero）。
4. 确认后重启 Zotero。

这里有个新手常犯的错误：选目录的时候选到了上一层或者下一层。判断标准很简单——你选中的那个文件夹里，必须能直接看到zotero.sqlite这个文件。选错的表现是重启后库是空的，一条文献都没有。遇到这种情况不用慌，回到设置里重新指定一次就行，数据本身没动。

还有一种更"硬核"的做法，直接改配置文件prefs.js，在里面加上一行：

user_pref("extensions.zotero.dataDir", "D:\\Data\\Zotero");

Windows 路径里的反斜杠要写成双反斜杠，这是转义规则。这种做法的好处是可以脚本化、批量部署，坏处是写错了 Zotero 会启动异常，还得手工改回来。除非你有明确需求，否则用界面设置更稳妥。

注意：切换数据目录不会自动搬文件，它只是告诉程序"去那儿找"。所以一定是先搬文件、再改设置，顺序反了会得到一个空库加一个找不到路径的报错。

3.4 迁移完成后必须做的三项硬校验

到这一步，界面打开了，条目列表出来了，很多人就觉得完事了。**条目在，不代表附件在；附件在，不代表文件完整。**下面三项校验，我每次迁移都做，加起来五分钟，能挡住绝大多数"看起来正常、用起来缺东西"的问题。

**第一项：条目数和分类数对得上。**在左侧分类树最底部的"我的文库"上右键，或者直接在中间列表看总数，和旧机器上记录的数字比对。误差在一两条以内可能是旧机器上有未同步的临时条目，差几十条就一定是出问题了。

**第二项：随机抽查附件能否打开。**不要只点最近看的几篇，要拉到底部随机点三到五个，特别是那种年份很老的、或者你自己扫描上传的 PDF。附件打不开有两种表现：一种是条目图标是灰色的（文件完全找不到），一种是能点但 PDF 阅读器报错（文件存在但内容损坏，通常是拷贝中断）。两种都要立刻停下来排查，别继续往下用。

**第三项：用文件层面的数字做最终确认。**这一项最有说服力。在新环境的命令行里跑一遍统计，和之前记下的基准数字对比：

# 文件总数 find /path/to/Zotero -type f | wc -l # 总占用空间 du -sh /path/to/Zotero

**如果文件数完全一致、总大小一致，那么可以说这次迁移是无损的。**如果文件数少了，说明有文件没拷过去；如果数量一致但总大小不一致，说明有文件被截断了。这两种情况的排查方式，在第 5 节里细说。

对数据库本身，还可以再跑一次完整性检查（需要系统里装了sqlite3命令行工具）：

sqlite3 /path/to/Zotero/zotero.sqlite "PRAGMA integrity_check;"

正常返回ok。返回任何其他内容，说明数据库文件有问题，这时候立刻停手，回头用备份里的zotero.sqlite或者zotero.sqlite.bak替换。注意这个命令要在 Zotero 完全关闭的情况下跑，否则可能因为文件被占用而误报。

4. 不同场景下的差异化处理

标题里列了四种场景：重装系统后、彻底删除旧版本后、安装新版后、更换电脑后。这四种看着都是"搬库"，但实际操作里的坑完全不一样，混在一起讲容易出问题，我一个个拆开说。

4.1 重装系统与彻底删除旧版本：抢救优先于迁移

这两种情况的共同点是：旧环境已经不存在了。重装系统意味着 C 盘被格式化，彻底删除版本意味着程序和数据都被清理。这时候你面对的不是"迁移"，是"数据抢救"，动作顺序和常规迁移完全反过来。

先说重装系统。如果你还没格盘，那就简单：在重装之前，把数据目录复制到非系统盘或者移动硬盘，重装完再搬回来，走第 3 节的流程。关键在于"重装之前"这四个字，很多人是装完系统才想起来 Zotero 里有东西，那就麻烦了。

如果已经格盘了，那只能走数据恢复路线：把硬盘拆下来接到另一台机器上，用文件恢复工具扫描未分配空间。成功的概率取决于格盘后有没有写入新数据——写入越多，恢复概率越低。这种情况下，第一件事是立刻停止往这块盘上写任何东西，包括不要在上面装恢复软件（装到别的盘）。恢复出来的文件里，zotero.sqlite和storage文件夹是重点，但恢复出来的zotero.sqlite很可能是片段，需要用sqlite3的.recover命令尝试重建。

再说"彻底删除旧版本"。很多用户的习惯是"卸载软件 + 手动删掉用户目录下所有带 Zotero 字样的文件夹"，这一删，库就真没了。如果你还有别的备份，从备份恢复；如果没有，检查两个地方：一是回收站（Windows 上手动删除的文件夹经常还在里面，而且 Zotero 的 storage 文件数量巨大，删除操作本身很慢，有些人删到一半就取消了），二是系统自带的文件历史记录或时间机器（Windows 的"文件历史记录"、macOS 的 Time Machine，如果之前开过，很可能有几天前的完整快照）。这两个渠道救回来的成功率，比很多人想象的高。

提示：卸载 Zotero 时，安装程序会问你要不要"同时删除我的 Zotero 数据"。这个选项默认通常是不勾的，也就是说正常卸载不会动你的库。真正把库删掉的，几乎都是卸载后手工去删文件夹那一步。

4.2 安装新版 Zotero：数据库单向升级，降级没有回头路

这条是我最想强调的一条，因为它的后果不可逆。

Zotero 从 5 到 6 再到 7，每次大版本更新都会升级数据库 schema。具体表现是：用新版本打开旧库时，程序会自动把zotero.sqlite的结构改成新版格式，同时把改之前的版本存成zotero.sqlite.bak。这个过程是单向的——升级后的数据库，旧版本程序读不了，会直接报错说"数据库版本过高"。

所以如果你打算升级，并且短期内可能需要退回旧版本（比如某个插件还没适配新版），升级前必须手工做一份完整备份，不能只依赖自动生成的.bak，因为那个.bak在下一次升级时会被覆盖。

升级迁移的正确顺序是：

1. 旧机器上完整备份数据目录（这一步前面已经讲过，多备份一份不吃亏）。
2. 新机器上装新版本Zotero，第一次启动空跑一次后退出。
3. 把旧数据目录整个搬过去，指向它，启动。
4. 程序会提示"正在升级数据库"，等它跑完，中途绝对不要强制关闭。库大的话这个过程可能几分钟，任务管理器里能看到磁盘在持续读写。
5. 升级完成后，先别急着用，跑一遍第 3.4 节的校验三项。
6. 确认没问题后，把升级后的zotero.sqlite再单独复制一份出来，命名成带日期的，比如zotero_20250101_after_upgrade.sqlite。

第 6 步的意义在于：万一你后面发现新版有某个功能不习惯想退回去，你手里有升级前的库（在备份里）和升级后的库（刚复制的这份），两个都能用，不会陷入"想退退不了"的死局。

还有一种情况是"新旧版本共存"。同一台机器上想装两个版本，用不同的配置目录启动，技术上可行（命令行加-profile参数指定不同 profile），但数据目录必须分开，两个版本不能指向同一个zotero.sqlite，否则高版本一升级，低版本立刻打不开。这种做法我只在测试场景用过，日常使用不推荐。

4.3 更换电脑与跨平台迁移：路径差异是最大的坑

换电脑本身不难，难在跨操作系统。Windows 换 Windows 是最顺的，路径格式一样，基本就是复制粘贴。Windows 换 macOS、或者反过来，就会碰到几个具体问题。

第一个是附件路径。Zotero 的附件分两种存法：一种是"存储文件"（Stored File），文件拷进storage/目录，用 item key 做文件夹名，这种跨平台完全没问题，因为路径是相对数据库的。另一种是"链接文件"（Linked File），文件留在原地，数据库里存的是一个绝对路径，比如D:\Papers\xxx.pdf。这种一换系统就全断了，因为 macOS 上没有 D 盘。

判断自己有没有链接附件的方法：在中间列表里随便看几个附件图标，链接附件的图标上会有一个小链条或者不同的角标。更彻底的办法是在"工具 → 开发者 → Run JavaScript"里跑一段统计（这里只是让你知道有这个东西，具体脚本按你的库结构调整）：

// 统计库中链接附件的数量 var items = Zotero.Items.getAll(Zotero.Libraries.userLibraryID); var linked = 0; for (let item of items) { if (item.isAttachment() && item.attachmentLinkMode === Zotero.Attachments.LINK_MODE_LINKED_FILE) { linked++; } } return linked;

如果数量不多，迁移后手工重新指向文件就行；如果数量上百，那就需要写脚本批量改路径前缀，把D:\Papers\替换成/Users/<用户名>/Papers/，这个后面第 5 节会讲思路。

**第二个是文件名大小写和非法字符。**Windows 的文件系统不区分大小写，macOS 默认也不区分但可以区分，Linux 严格区分。如果你从 Linux 往 Windows 搬，两个只差大小写的文件夹会被合并，虽然罕见但要留意。反过来，Windows 文件名里允许的一些字符（比如某些符号），在 Linux 上可能不合法，拷贝时报错。遇到这种情况，先记下报错的文件名，单独处理。

**第三个是权限。**从 Windows 的 NTFS 往 Linux 的 ext4 搬，文件的权限位会丢。对 Zotero 来说这通常不影响使用（它自己管理 storage 里的文件），但如果你的数据目录放在系统目录下，可能出现"读得到写不了"的情况。解决办法是把数据目录放在用户主目录下，用当前用户的所有权：

sudo chown -R $(whoami):$(whoami) /home/<用户名>/Zotero

5. 常见故障与排查实录

迁移这件事，成功的时候风平浪静，出问题的时候症状都很像：条目在、附件打不开；或者干脆库是空的。下面这几个是我自己遇到过的，也有同行反馈过的，按出现频率排序，每个都给出排查路径和解决办法。

5.1 条目全在但附件全是灰色

这是最高频的问题，没有之一。症状是文献列表正常显示，但每条旁边的附件图标是灰色的，双击提示"找不到文件"。

**排查第一步：看storage文件夹在不在。**打开数据目录，确认storage文件夹存在且里面有大量子文件夹。如果storage是空的或者根本不存在，那就是搬的时候漏了，回到备份里把storage补拷过去即可。

排查第二步：看storage里的子文件夹名和数据库能不能对上。Zotero 用 item key（8 位字符）命名子文件夹。如果子文件夹在，但数据库里记录的 key 对不上，说明你搬过去的是另一个版本的数据库和这个 storage 混在一起了。这种情况常见于"备份里同时有新旧两份数据，拷的时候拷串了"。解决办法是确认备份的完整性，整份重拷，不要混搭。

**排查第三步：检查是不是链接附件。**如果storage里根本没有对应的文件夹，那这个附件大概率是"链接文件"类型。链接附件在数据库里存的是绝对路径，换机器后路径变了就失效。修复方式是右键附件 → "显示文件"，如果提示路径不存在，就手工重新定位；批量的话，用"工具 → 开发者 → Run JavaScript"批量修改attachmentPath字段里的路径前缀。

**排查第四步：文件权限。**在 Linux 或 macOS 上，如果数据目录是从别的机器拷过来的，文件属主可能是旧的用户 ID（比如 UID 1000 换成了 UID 1001），导致当前用户读不了。用一个命令看一眼：

ls -l ~/Zotero/storage | head

如果属主不是当前用户，用chown -R改回来。

5.2 改了数据目录，打开还是空库

症状是明明在设置里指定了新目录，重启后左侧分类树是空的，中间列表什么都没有。

原因通常是路径指错了一层。Zotero 要求的路径是"直接包含zotero.sqlite的那个文件夹"，而你选的可能它的上一级（比如选了D:\Data，而数据库在D:\Data\Zotero），或者下一级（选了D:\Data\Zotero\storage）。

判断方法：在设置界面选中路径后，退出来用文件管理器打开那个路径，看第一层有没有zotero.sqlite。没有就说明选错了。修改的方式是回到设置重新点"自定义"，重新选一次，选对了重启就能看见。

还有一个隐蔽的原因：同一台机器上装了多个 Zotero 版本，配置文件是分开的。你在 A 版本的设置里改了路径，启动的却是 B 版本。这种情况检查一下启动的是哪个程序，或者干脆把不用的版本卸掉。

5.3 数据库被锁、提示"文件正在使用"

这个错误通常出现在两种情况：一是旧机器上的 Zotero 进程没退干净，数据库文件还带着锁；二是你把数据目录放在了网络盘或者同步盘的挂载点上，文件系统不支持 SQLite 需要的那种文件锁。

第一种情况的处理方式是回到 2.1 节，把进程彻底杀掉。如果杀完还有zotero.sqlite-journal残留，别删，让 SQLite 自己回滚。

第二种情况更值得说：不要把数据目录放在网络共享盘或者某些同步目录里。SQLite 依赖操作系统的文件锁机制，网络文件系统（NFS、SMB）上的锁实现经常不完整，表现是随机出现的"database is locked"，严重时数据库会损坏。同步目录（比如被实时同步的文件夹）也会有问题——同步工具可能在 Zotero 写入的瞬间去读文件，读到一半的状态。

正确的做法是：数据目录放在本地磁盘，需要备份时用"关闭 Zotero 后整目录复制"的方式，而不是让同步工具实时盯着这个目录。

5.4 常见问题速查表

下面这张表是我自己整理的，遇到问题先查表，能省下不少瞎试的时间。

6. 迁移之后的长期维护习惯

迁移只是一次性动作，迁移完不代表以后就安全了。我自己这几年的教训是：真正让数据丢掉的，往往不是那一次迁移，而是迁移之后的日常疏忽。所以最后分享几个我已经固化成习惯的做法，成本都很低。

6.1 用"版本化快照"代替"覆盖式备份"

很多人备份的方式是"把整个文件夹复制到备份盘，覆盖上一次的"。这种做法有个致命缺陷：如果某次复制的时候源目录已经损坏了（比如数据库被写坏），你覆盖过去之后，唯一一份好的备份也没了。

我的做法是每次备份生成一个带日期的独立目录，比如Zotero_20250101、Zotero_20250201，保留最近三到四份，旧的再删。这样占用的空间是可控的，但任何一次出错都能回退到"上一个好的状态"。

库特别大的话，可以用增量同步工具做版本化，rsync配合--link-dest参数就能做硬链接式的增量备份，只存变化的部分，空间占用接近单份：

rsync -aH --delete --link-dest=/backup/Zotero_latest ~/Zotero/ /backup/Zotero_20250201/

--link-dest的意思是：和上一次备份相比没有变化的文件，用硬链接指过去，不占额外空间。这样既能保留完整的历史快照，又不会把硬盘撑爆。

6.2 别把"同步"当成"备份"

这句话我想单独说，因为它是最普遍的误解。

**同步解决的是"多台设备看到同一份数据"，备份解决的是"任何时候都能恢复到某个历史状态"。**这两件事在技术上完全不同。同步的典型失败场景是：你在 A 机器上误删了一个分类，同步一秒后，B 机器上也没了；你在某台机器上打开了一个损坏的数据库，同步把它扩散到所有设备。备份则不会，因为它是只读的历史快照。

所以我的配置是：手动整目录备份打底（本地 + 异地），元数据同步作为多设备便利性补充，附件各机各存。这样做的好处是，即使同步那边出了任何幺蛾子，本地备份永远能兜住。

还有一个细节：如果你用第三方同步盘同步storage目录，一定要注意不要让它实时同步。前面说过 SQLite 对文件锁敏感，实时同步工具可能在 Zotero 写入时去读文件。比较稳妥的做法是设成"定时同步"，或者干脆关掉这个文件的同步，靠 Zotero 自己的同步机制处理元数据。

6.3 迁移完成后这份"体检清单"建议存下来

每次迁移结束，我都会跑一遍下面这套流程，十几分钟，但能让心里彻底踏实。整理成清单形式，你可以直接拿去用：

1. 条目总数与旧机器一致（误差为 0 或个位数）。
2. 分类树结构完整，没有出现"未分类"里塞满东西的情况。
3. 随机抽查五个附件，跨度覆盖最新和最老的文献。
4. 文件总数与基准数字一致。
5. 数据目录总大小与基准一致。
6. PRAGMA integrity_check返回ok。
7. 打开一篇带笔记的文献，确认笔记内容和格式完整。
8. 插入一篇文献到文档里，确认引文格式能正常生成（说明styles也搬过来了）。
9. 把升级后的数据库单独复制一份存档。
10. 在备份盘上确认新旧两份数据都在，然后才清理旧机器的数据目录。

这套清单里，第 7 和第 8 条是最容易被忽略的——很多人只验证"文献在不在"，不验证"笔记和引文格式对不对"。而笔记是纯文本加 HTML 存在数据库里，引文样式存在styles目录，两者都不在storage里，搬的时候最容易漏。

最后说个我自己的小习惯：每次迁移完，我会在库里新建一个叫"迁移记录"的分类，写一条笔记，记下日期、从哪个路径搬到哪个路径、版本号变化、文件总数。听起来有点强迫症，但当下次再迁的时候，这条笔记能省掉我半小时的"上次是怎么弄的来着"的回忆时间。数据管理这件事，把过程记下来，比记住结果有用得多。