我终于搞清楚了：Windows 上的 Node.js 到底是谁在管理

这次把以前备份下来的 Hexo 博客重新跑起来，本来只是想装一下依赖、写点文章，结果顺手把一个拖了很久的问题也搞明白了：我这台 Windows 机器上的 Node.js 到底是谁在管理？

之前我的印象一直很模糊。我记得早些年是用 scoop 装过多个 Node 版本，互相覆盖着用；后来似乎又换了别的工具，但时间太久，自己也忘了。
这次借着恢复博客环境，我把这件事彻底捋了一遍，顺手也把 vfox、PowerShell 启动速度和 Hexo 的兼容性问题一起搞清楚了。

一、结论先说

先给最终结论，免得后面越看越乱：

• 当前 Node.js 是由 vfox 管理的，不是直接由 scoop 管理。
• scoop 现在的作用，是安装了 vfox.exe 这个工具本体。
• 当前实际使用的 node 路径指向了 C:\Users\cy\.version-fox\cache\nodejs\current\node.exe。
• 我后来把 Node 从 22.12.0 切到了 20.20.2。
• 切换到 Node 20 之后，Hexo 启动时那个 punycode 的弃用警告也消失了。

也就是说，我现在真正的 Node 版本管理工具是 vfox。

二、我是怎么确认的

确认方式其实很直接，主要看这几个东西：

1
2
3
4
5

where.exe node
where.exe npm
where.exe vfox
node -v
npm -v

查出来以后，信息非常明确：

• node 指向 C:\Users\cy\.version-fox\cache\nodejs\current\node.exe
• vfox 指向 D:\Scoop\shims\vfox.exe

这说明两件事：

1. scoop 没有直接接管当前 node
2. scoop 安装了 vfox，而 vfox 在接管 Node 版本

另外，C:\Users\cy\.version-fox\.tool-versions 里记录的版本信息也能对上。
切换完成后，里面写的是：

1

nodejs 20.20.2

这就基本没悬念了。

三、为什么我把 PowerShell 里的 vfox 配置注释掉了

还有一个我之前一直记得的点：我主动把 PowerShell 里关于 vfox 的初始化给注释掉了。

原因很简单：它会拖慢 PowerShell 的启动速度。

我个人的 profile 里原来保留过这样的内容：

1

#Invoke-Expression "$(vfox activate pwsh)"

问题在于，vfox 并不是一个“只读配置、瞬间结束”的东西。
它在启动时通常要做这些动作：

• 计算当前该激活哪个版本
• 处理 PATH
• 读取 .tool-versions
• 读取插件信息
• 访问 C:\Users\cy\.version-fox\temp
• 写入临时状态或缓存

这些动作叠加起来，PowerShell 打开速度就会明显变慢。

所以后来我干脆把它注释掉了。

四、既然注释了，为什么 node 还是能正常用

这也是我之前有点糊涂的地方。

直觉上看，既然 vfox activate pwsh 没执行，那 Node 为什么还能正常用？

这次排查之后，答案也清楚了：因为系统环境里已经把 Node 的路径指到了 vfox 的 current 目录。

也就是说，现在不是靠 PowerShell 每次启动时动态激活，而是 PATH 本身已经能命中这里：

1

C:\Users\cy\.version-fox\cache\nodejs\current

这带来的效果其实还挺实用：

• PowerShell 启动更快
• node 和 npm 仍然可以直接用
• 需要切换版本时再手动执行 vfox 命令

对我这种主要拿它写博客、偶尔折腾环境的人来说，这反而是一个挺平衡的状态。

五、顺手解决了 Hexo 的 Node 兼容性问题

这次最开始其实是在恢复我的 Hexo 博客环境。

博客本身是：

• Hexo 7.3.0
• Fluid 1.9.8

一开始在 Node 22.12.0 下，Hexo 虽然能跑，但启动时会出现这样的警告：

1

[DEP0040] DeprecationWarning: The `punycode` module is deprecated.

后面顺着依赖链查了一下，本质上是某些旧依赖在新版本 Node 下触发了弃用提示，不是博客本身坏了。
虽然不影响运行，但看着总归不舒服。

后来我直接把 Node 切到了 20.20.2，再跑 Hexo，警告就没有了。

这也让我得到一个更实用的结论：
像 Hexo 这种依赖链里有不少老包的项目，用 Node 20 这类更稳的 LTS 版本通常更省心。

六、现在这套环境我准备怎么用

折腾完以后，我决定保持现在这种方式，不再让 vfox 自动注入 PowerShell。

我自己的建议是：

• 不在 PowerShell 启动时自动执行 vfox activate pwsh
• 需要切换版本时手动执行 vfox install 和 vfox use
• 跑 Hexo 这类老牌静态博客项目时优先用 Node 20

常用命令也不复杂：

安装版本：

1

vfox install nodejs@20

全局切换：

1

vfox use -g nodejs@20

验证：

1
2
3

node -v
npm -v
where.exe node

七、这次排查给我的实际收获

这类环境问题最烦的地方就在于：机器能用，但自己已经忘了它为什么能用。

时间一久，就很容易出现这种情况：

• 记得自己以前折腾过
• 记得好像换过工具
• 记得某些配置动过
• 但具体是怎么串起来的，完全说不清

这次把 vfox、scoop、PowerShell、Hexo 和 Node 版本关系重新理清之后，我最大的感觉不是“学到了新东西”，而是终于把一堆残留认知债清掉了。

以后如果我再恢复环境，或者把博客迁移到别的机器上，至少不会再从“我到底是怎么管理 Node 的”开始懵住。

八、最后的结论

一句话总结这次排查：

我当前 Windows 上的 Node.js 是由 vfox 管理的，scoop 只是安装了 vfox；为了保住 PowerShell 启动速度，我把 vfox 的自动激活注释掉了，而 Hexo 这类项目放在 Node 20 上跑更稳。

如果你也和我一样，电脑用久了以后开始忘记自己当初怎么配环境，不妨趁着下次修项目的时候顺手查一遍。
很多时候，查清楚一台机器的真实状态，比重装一遍更有价值。