目录存在，不代表环境可用

Windows 开发机使用久了以后，磁盘里很容易同时出现多个 JDK、Python、Node.js、Go、Rust、LLVM、Visual Studio、CUDA 和 Android SDK。最危险的判断方式是：看见目录就宣布“已经安装”。

我把环境状态分成四层：

层级 要回答的问题 证据
存在 文件是否真的在磁盘上 明确路径、文件版本
可达 新终端能否解析命令 Get-Command、where.exe
可执行 工具能否正常启动 --version、-version
可构建 能否完成最小真实任务 编译、链接、测试、运行

只有走到第四层，才能把一条工具链记为“真正可用”。

第一步：在干净终端里确认命令来源

不要只在已经激活 Conda、NVM 或 Visual Studio 的旧窗口里检查。重新打开 PowerShell，再执行：

1
2
3
4
5
6
Get-Command java, javac, py, python, go, node, pnpm, rustc, cargo, clang, cmake, ninja -All

where.exe java
where.exe python
where.exe node
where.exe pnpm

Get-Command -All 能看到 PowerShell 别名、函数、脚本和可执行文件的全部候选；where.exe 更接近传统 PATH 搜索。两者一起使用，可以发现 Windows App Execution Alias、Scoop shim、Corepack 脚本和真实二进制之间的优先级冲突。

然后直接询问工具自身：

1
2
3
4
5
6
7
8
9
10
11
javac -version
py --version
go version
node --version
pnpm --version
rustc --version
cargo --version
clang++ --version
cmake --version
ninja --version
nvcc --version

如果某个目录存在，但命令不可达，就把它记录为“已存放、未接入”，而不是急着向全局 PATH 继续加路径。

第二步：把专用终端和普通终端分开

MSVC、MSBuild 和 Windows SDK 已安装，却无法在普通 PowerShell 中直接调用，并不一定是故障。Visual Studio 的开发者终端会注入编译器、链接器、SDK 和 MSBuild 所需的一组环境变量。

微软推荐通过开始菜单或 Visual Studio 的“工具 → 命令行”打开 Developer PowerShell，也可以用 Launch-VsDevShell.ps1 初始化，详见 Visual Studio 开发者命令行文档。

在开发者终端中再验证：

1
2
3
4
cl
link
msbuild -version
$env:VSCMD_VER

因此审计报告应该写成“MSVC 需要专用终端”，而不是“cl 不在普通 PATH，所以 Visual Studio 损坏”。

第三步：识别多版本管理器的真实选择

多版本环境必须同时记录“库存”和“当前入口”。

Python

1
2
3
py -0p
Get-Command python -All
python -c "import sys; print(sys.executable); print(sys.version)"

py、裸 python 和 Conda 环境里的 python 可能分别指向不同解释器。安装依赖时使用：

1
2
python -m pip --version
python -m pip install -r requirements.txt

这样可以确保 pip 与当前解释器属于同一个环境。

Node.js

1
2
node -p "process.execPath"
Get-Command node,pnpm,corepack -All

NVM 的链接目录、Corepack 和独立 Node 运行时可能同时存在。不要只记录版本号，还要记录命令最终解析到了哪里。

Go 与 Java

1
2
3
go env GOROOT GOPATH
$env:JAVA_HOME
Get-Command java,javac -All

环境变量指向一个版本，而 PATH 命中另一个版本，是最常见的“能启动但构建异常”来源之一。

第四步：审计 PATH 的重复项与死路径

1
2
3
4
5
6
$machine = [Environment]::GetEnvironmentVariable('Path', 'Machine') -split ';'
$user = [Environment]::GetEnvironmentVariable('Path', 'User') -split ';'

$all = @($machine + $user) | Where-Object { $_ }
$all | Group-Object | Where-Object Count -gt 1 | Select-Object Count, Name
$all | Where-Object { -not (Test-Path $_) }

这里不要直接自动删除。PATH 里的变量可能需要展开，网络盘也可能临时离线。审计动作应该只生成候选清单，再由人工确认来源和影响。

第五步：用最小构建完成验收

版本输出只能证明程序启动了，不能证明编译链完整。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Java
javac Main.java
java Main

# C/C++：LLVM + Ninja
cmake -S . -B build -G Ninja `
  -DCMAKE_C_COMPILER=clang `
  -DCMAKE_CXX_COMPILER=clang++
cmake --build build
ctest --test-dir build --output-on-failure

# Rust
cargo fmt --check
cargo clippy -- -D warnings
cargo test

# Go
go test ./...
go build ./...

# Python
py -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip --version

# Node.js
corepack enable
pnpm install --frozen-lockfile
pnpm test
pnpm build

CUDA 还要区分显卡驱动报告的兼容上限与本机真正安装的 Toolkit。nvidia-smi 显示的 CUDA 数字不等于 nvcc --version 的编译工具包版本；需要编译扩展时，以 Toolkit 和项目要求为准。

报告应该如何下结论

最终我使用四档状态：

1
2
3
4
直接可用：新终端可达，并通过最小构建
专用终端可用：需要 Developer PowerShell 等初始化
显式路径可用：文件存在且可执行，但不应加入全局 PATH
不完整：只有目录或部分组件，不能完成目标构建

一次好的环境审计不追求“所有工具都全局可用”，而是要让每条构建链的入口、版本、前置条件和失败边界都可解释。PATH 不是收藏柜，放得越多并不会越专业。