Wox v2 迁移完全指南：配置同步、插件兼容与界面变化

迁移之前先做一次盘点

跨版本迁移最容易出问题的不是操作步骤，而是没有先搞清楚自己依赖什么。装完 v2 才发现最常用的那个插件不兼容，这时候回退的成本已经很高了。

盘点要回答三个问题：

1. 我现在装了多少插件，哪三个是「每天必用」的？
2. 我配了多少别名，哪些是肌肉记忆已经形成的？
3. 我改过哪些设置（热键、索引范围、主题）？

这三个问题的答案就是你的迁移清单。如果第一题里「每天必用」的插件在 v2 上都没有对应版本，那这次迁移就不该做。

第一步：配置能不能带过去

好消息是配置格式是纯文本，理论上可以人工迁移。坏消息是跨版本时字段结构可能变化，直接覆盖过去不一定被识别。

务实的做法是分两类处理：

别名与热键：手工重配更安全

别名的数量通常不多（十个左右），手工重配一遍只要十几分钟，而且能顺便清理掉已经用不上的条目。

热键同理。重配的时候正好重新考虑一遍键位是否合理——很多人从 v1 迁过来，会顺手把当年随手设的热键改成更顺手的组合。

索引与主题：重新设置

索引范围、界面主题这类设置，两个版本的选项结构差异较大，直接迁移容易出问题。在新版里按自己的习惯重设一遍更稳妥。

索引范围重设时，可以顺便做一次优化：把系统目录、程序目录、缓存目录排除掉，只保留真正需要检索的位置。

第二步：插件兼容怎么处理

这是迁移中最硬的一道坎。两个版本的插件体系不兼容，v1 的插件在 v2 上无法使用。

处理顺序建议是：

1. 先只装主程序，不装任何插件，确认基础功能正常（能呼出、能搜程序、能计算）
2. 按盘点清单逐条找替代。常用的功能通常有对应实现，冷门的可能没有
3. 找不到替代的，评估能不能用别名顶上。很多插件本质是「执行一条命令」，别名就能覆盖
4. 仍然缺的，接受它暂时没有，或者考虑回退

第 3 条值得展开：装插件的真正理由应该是「别名做不到」，而不是「装起来方便」。迁移正好是一次清理机会——把那些其实用别名就能解决的功能从插件降级成别名，启动器会更快。

第三步：界面变了怎么找回功能

新版重排了设置结构，很多选项换了位置。这带来的困惑往往被误判成「功能没了」。

几个常被问到的位置变化：

• 插件管理通常在扩展或插件相关分组下
• 热键设置通常在通用或快捷键分组下
• 主题与外观通常独立成一个分组
• 索引与文件搜索通常在文件或搜索相关分组下

如果确实找不到，先去官方文档或仓库的说明里查一遍。新版界面还在演进，位置调整比较频繁，社区里往往有最新的截图。

迁移后必须验证的五件事

• 热键能正常呼出，且不与常驻软件冲突
• 输入一个确定存在的程序名，能搜到并启动
• 输入一个确定存在的文件名，能搜到（验证索引是否接上）
• 每个别名都实际执行一遍，而不是只看它在列表里
• 常用的两三个插件能正常加载并响应

最后一条尤其重要：别名「看起来还在」和「实际能执行」是两回事。迁移时字段结构可能有变化，只有真正跑一遍才能确认。

什么时候该回退

不是所有迁移都该坚持到底。出现下面三种情况，回退是更理性的选择：

1. 核心插件没有替代，且你的工作流高度依赖它
2. 遇到阻塞性缺陷，比如索引不稳定导致体验下降明显
3. 配置无法等价重建，导致你要损失大量已形成的肌肉记忆

回退的成本很低：卸载新版、装回旧版、把备份的配置目录还原回去。这也是为什么第一步一定要备份。

迁移完之后该做的事

迁移成功之后，有两件事值得立刻做，能避免下次迁移重复踩坑：

• 把新的配置目录再备份一次，作为「v2 基线」单独存放
• 把当前的别名与插件清单写成文档，记录每个别名的用途

第二件事看起来多余，但它是你下次迁移时最有价值的东西——它把「我的工作流是什么」从肌肉记忆变成了可查的文字。

一个判断：现在要不要迁

抛开所有技术细节，只问一个问题：你现在用的版本，有没有让你真正难受的地方。

没有，就别迁。启动器是每天要用几十次的基础设施，稳定性比新功能重要得多。迁移的收益通常是一次性的新鲜感，而代价是持续的兼容性麻烦。

有明确痛点（比如界面太旧看不清、需要跨平台统一），那迁移就有正当理由，值得承担成本。