Wox 更新与新版本：v1 和 v2 到底该用哪个

为什么会同时存在两个版本

Wox 的 v2 不是 v1 的简单升级，而是一次架构重写。重写的动机很实际：v1 的技术栈偏老，跨平台支持和新界面能力都受限于早期设计。

重写带来的直接结果是插件体系不兼容。v1 的插件基于旧架构，v2 换了新的扩展机制，两边的插件不能互用。这就是为什么你会看到「同一个插件有人说能用、有人说装不上」——他们跑的不是同一个版本。

于是在过渡期内，两条线并行：v1 继续维护、生态成熟、教程多；v2 功能更新、界面更好、生态还在追。

两条线的实际差异

注意「alpha」这个词。它意味着功能会变、接口可能调整、遇到的问题不一定有现成答案。这不代表它不能用，而是代表你要有自己解决问题的准备。

该选 v1 的四种情况

• 你是第一次用 Wox，还在建立使用习惯
• 你依赖某些特定插件，且它们只在 v1 上可用
• 你在公司电脑上部署，需要稳定可预期
• 你希望遇到问题时能搜到现成答案

对绝大多数用户，v1 是更务实的选择。它的功能并不缺，缺的只是新界面。

该选 v2 的三种情况

• 你需要 macOS 或 Linux 支持，希望三端体验一致
• 你对界面定制有较高要求，v1 的样式无法满足
• 你愿意接受不稳定性，并具备自己排查问题的能力

另外，如果你想用 JavaScript 写自己的插件，v2 是更合适的基础——v1 的 Python 插件体系对新扩展的支持不如 v2 开放。

升级之前必须做的三件事

第一件：备份配置目录

把 %APPDATA%\Wox\ 整个目录复制出来。这里包含你的热键、别名、插件设置，是唯一无法通过重装恢复的东西。

第二件：导出插件清单

列出你当前装的所有插件，标注哪些是「必须有」、哪些是「可有可无」。跨版本迁移时，这份清单是你判断「还能不能回去」的依据。

第三件：确认插件兼容性

对着清单逐个确认目标版本是否支持。这一步最容易被跳过，也最容易在迁移后变成麻烦——装完发现最依赖的那个插件用不了，只能退回。

升级后常见的不适应

插件全部失效

这是跨版本迁移最常见的现象，原因就是插件体系不兼容。解决办法只有两种：找对应版本的新插件，或者退回旧版本。

别名规则变了

部分别名的语法在新版里可能调整。迁移后建议把每个别名都实际执行一遍，而不是只看它还在列表里。

界面找不到设置入口

新版重排了设置结构，很多选项换了位置。这不是功能缺失，只是位置变了，耐心找一遍即可。

怎么判断「该不该现在升级」

用一个简单的问题就能判断：你现在用的版本，有没有让你真正难受的地方。

如果没有，就别升级。启动器是基础设施，稳定比新功能重要得多。升级带来的收益通常是一次性的新鲜感，而风险是持续的兼容问题。

如果确实有痛点（比如界面太旧、需要跨平台），那升级就有明确收益，值得承担迁移成本。

关于「更新提示」的建议

启动器不需要保持最新。一个务实的策略是：

1. 跨大版本（v1 → v2）不主动升，除非有明确需求
2. 同版本内的小更新可以跟进，风险较低
3. 升级前先备份配置，出了问题能回退

这套策略的道理很简单：你依赖的是「每天按一下热键就能用」，而不是「用上最新版」。

版本选择的四个常见误判

选版本时的纠结，大多来自四个认知偏差。

误判一：新版本一定更好

软件不像硬件，新版本不等于更成熟。尤其是标注 alpha 的版本，它的定位是「功能验证」而不是「稳定交付」。用新版本的合理性来自「你需要它的新能力」，而不是「它比较新」。

误判二：旧版本等于停止维护

双版本并行期间，旧版本通常仍在维护。它的生态、文档、问题解答都比新版本成熟，对绝大多数人来说是更省心的选择。

误判三：可以随时切回去

技术上可以，但成本比想象中高。一旦你在新版本里重新配了别名、装了新插件、形成了新习惯，切回去意味着这些全部作废。所以「先试试，不行再退」这句话在跨版本场景里并不轻松。

误判四：版本号越大功能越全

跨版本重写往往伴随功能取舍。某些在旧版本里顺手的能力，新版本可能还没补齐。升级前建议对照自己的高频功能逐条确认，而不是看总体功能列表。