当我使用内置的“环境变量”对话框或类似“ 路径编辑器”的工具更新PATH ，然后打开命令提示符时，对PATH所做的更改将不会在控制台中注册，具体取决于命令提示符所在的位置从开始。
例如，如果我编辑PATH，然后从“开始”菜单或桌面上的快捷方式启动cmd.exe，则我的PATH看起来很好：它已成功更新；但是，如果我从“开始”菜单或“桌面”以外的其他任何地方从快捷方式启动cmd.exe，则不会读取新的PATH，而会得到旧的路径。真奇怪
我试过从桌面上的快捷方式运行命令提示符，它工作正常；然后，我将完全相同的快捷方式复制到桌面上的子文件夹，然后出现非更新的PATH问题。
我意识到这很难解释，因此我创建了一个截屏视频来展示此问题的实际执行情况。
这是该屏幕录像中所示的“命令提示符”快捷方式的屏幕截图：
这是在Windows Vista Home Premium SP2上。
Answers:
当您启动一个新进程（例如新命令行）时，它将从启动它的进程中获取环境变量。路径更新后，只有执行更新的进程才能知道其已更改，并且设置只有在您重新登录（针对每个用户的设置）或重新引导（针对系统范围的设置）后才会传播。
echo $PATH不起作用。我以为这是新鲜的，但是直到我关闭了所有的Git Bash标签和ConEmu才出来。
正如Rowland所建议的那样，当启动一个新进程时，它将从启动它的进程中读取环境变量。因此，当从“ 开始”菜单或桌面启动命令提示符时，它会读取环境变量explorer.exe，如所建议的那样，它会检测到注册表中环境设置的更改，因此我从命令提示符处看到了我的新PATH。桌面或开始菜单。
我在发布的截屏视频中看不到PATH更新的原因是因为我最初是使用FARR创建FindAndRunRobot.exe父进程启动了资源管理器窗口。FARR不会自动检测环境变化，因此，由此产生的子进程不会采用新的PATH。我在资源管理器中还设置了“ 在一个单独的进程中启动文件夹窗口 ”选项，这意味着我打开的所有explorer.exe窗口是在FARR打开第一个窗口之后打开的，FARR也是FARR的子窗口。
通过关闭“ 在单独的进程中启动文件夹窗口 ”选项，explorer.exe不会在FARR下创建新进程，这解决了我的问题。但是，我也直接从FARR启动控制台窗口和其他功能。这些还可以获取旧的环境设置。如果重新启动FARR，则将传播新的环境设置。
这是Process Explorer的屏幕截图，显示了从FARR衍生的流程。explorer.exe除非我重新启动FARR，否则所有这些进程都不会从顶层接收新的环境设置：
explorer过程将检测注册表中的环境更改（该对话框属于rundll32），并自动更新其自身的环境。（至少在XP中是这样做的。）这就是为什么cmd从快捷方式启动时可以看到更改的原因。