npm install 失败时，最后一行常常只是某个脚本退出。真正的问题可能是找不到编译器，也可能是预编译二进制下载失败后转入了本地编译。下面两次 2018 年 Windows 故障分别对应这两条排查路径。

MSB4132：工具版本选择失败

第一台 Windows 10 64 位电脑报错：

MSBUILD : error MSB4132:
无法识别工具版本“2.0”。可用的工具版本为“4.0”。

当时通过把 npm 的全局 msvs_version 设置为 2012 继续安装。这是那个环境中的历史处理，不表示现在应该安装 VS 2012 或全局指定它。

更有用的检查顺序是：哪个依赖触发了原生构建、调用的是哪一份 node-gyp、它发现了哪套 MSBuild/Visual C++，失败发生在工具发现、生成工程还是编译阶段。当前 node-gyp 文档 列出 Python 和 Visual C++ 构建环境要求，旧工程必须再对照它实际使用的 node-gyp 版本。

node-sass：先辨别下载失败还是版本不支持

第二次日志停在 node-sass@4.5.2 postinstall。当时缓存目录缺少二进制文件，曾把 4.7.2 缓存中的 win32-x64-57_binding.node 复制到 4.5.2 目录后重试；另一台电脑又遇到不同结果。

文件名中的操作系统、架构和模块 ABI 都有意义。“都是 Windows 64 位”不足以判断能否加载。包版本、Node 版本与 ABI 必须一起匹配，跨 node-sass 版本复制文件也不是受支持的通用修复。

可先只读记录当前运行时：

node --version
node -p "process.platform + ' ' + process.arch"
node -p "process.versions.modules"
npm ls node-sass node-gyp --all

npm ls 可能因依赖不完整而非零退出，仍可作为诊断信息。接着查日志中的二进制下载 URL、状态和回退编译信息；下载失败不等于没有对应二进制，没有对应二进制也不一定能靠重试解决。

旧项目应隔离，新项目不再采用 Node Sass

Node Sass 仓库 已归档并说明维护结束，也保留了 Node/ABI 兼容表。维护老项目时，应先固定锁文件、运行时和构建工具，在隔离环境验证；计划替换 Sass 实现时另做样式回归。

不要用关闭 TLS 证书校验、下载未知二进制或持续修改全局 npm 配置来试错。更换实现、安装完成和最终样式一致是三件事，不能只凭 postinstall 不再报错就认定迁移成功。