我把一个powershell片段放在一起，它重新排序了WindowsApps和Python文件夹，所以Python是第一个。以管理员身份运行:

$appsFld="$env:USERPROFILE\AppData\Local\Microsoft\WindowsApps"; 
$pyPath=(Resolve-Path "$env:USERPROFILE\AppData\Local\Programs\Python\Python*\")
$Env:Path = (($Env:Path.Split(';') | Where-Object { $_ -ne "$appsFld" }) -join ';'); 
$Env:Path = (($Env:Path.Split(';') | Where-Object { $_ -ne "$pyPath" }) -join ';'); 
$Env:Path += ";$pyPath";
$Env:Path +=";$appsFld";
[Environment]::SetEnvironmentVariable("PATH", "$Env:Path", "Machine")

然后我可以很好地运行python:

> python
Python 3.10.7 (tags/v3.10.7:6cc6b13, Sep  5 2022, 14:08:36) [MSC v.1933 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit

这是一个实现神奇功能的PowerShell脚本。

Remove-Item $env:USERPROFILE\AppData\Local\Microsoft\WindowsApps\python*.exe

您可以手动将Python添加到Windows路径，如下所示:

Start the Run box and enter sysdm.cpl Go to the Advanced tab and click the Environment Variables button Now you’ll need to locate the relevant Python paths Here is how a Python application path looks like: And this is how a Python Scripts path looks like: Select the Path variable, press edit and add both paths (Python application and Python Scripts) If it doesn't show, press new instead of edit and fill the New User Variable box This is how my Variable value looks like: C:\Users\Ron\AppData\Local\Programs\Python\Python37-32;C:\Users\Ron\AppData\Local\Programs\Python\Python37-32\Scripts

就是这样!您只是将Python添加到Windows路径。

来源:Data To Fish

因为这是一个常见的问题，这似乎是一个典型的问题，我想尝试对Python 3.7 Windows Store惨败(TM)进行一个完整的概述。

为什么会发生这种情况?

两件事的融合:2011年为Windows推出的Python启动器(以下简称py)，以及2019年5月的Windows 10更新，显然是为了让Windows用户更容易安装Python。

哦。事实证明，安装路径并不好;它绕过了“冗长的”安装向导…其中包含一些用户认为非常有用的选项。这也引发了其他问题。更不用说它只是以稍微非标准的方式工作，对文件系统访问有限制，因为它是一个商店应用程序，最初不能由py....启动

好吧，但是为什么这些因素会导致问题呢?

Since the introduction of py, by default, Windows Python installers do not add the new Python install to the PATH. Why? Because the entire point of py is that it uses its own logic to find a Python installation, based on some combination of command-line switches and possibly the source file's own shebang line. Now your source files can be associated with py instead of any particular python.exe, and you can get Linux-like behaviour when double-clicking a file. Meanwhile, by running py at the command line, you have easy access to whatever you need, and you don't have to think about which version of Python was installed most recently. So there's seemingly no good reason to put any of those Python installations on the PATH. It only risks confusing you when, for example, the most recently installed version isn't the most up-to-date one. Right?

在更新中，Windows 10将“python.exe”放入Windows应用程序相关文件夹，这是一个用于打开微软商店链接的包装应用程序。我们的想法是，它在PATH上，但接近结尾;所以如果你安装了Python，它就会被使用，否则包装器就会被调用，并帮助你安装Python——这样你就可以运行你朋友在Discord上发给你的那个随机的、完全信任的。py文件。

如果你安装的Python在PATH上，它会完美地工作。

哦。

(但是，你知道，py在8年前就已经被引入了。你可能会认为微软的某个人已经意识到了这个潜在的问题。也许他们可以做一个真正的脚本来检查是否存在C:\Windows\py.exe之类的，而不是一个特殊的快捷链接。)

那么我有什么选择呢?

You can check the option to add new Python versions to the PATH when you install them, and deal with the fact that python at the command line means a specific one of them. If you need to change that, you can manually tweak your PATH variable. You can just manually tweak the PATH variable after the fact. (or "Modify" a Python installation to fix it.) This is covered in several other answers. Independently of that, you can disable the wrappers, as shown in the top answer. You should probably do this anyway; seeing python fail at the command line is less aggravating than dealing with a random GUI window popping up and offering to install something for you, especially when you know you have it already. If you want to keep the PATH empty, consider using virtual environments for your projects. Whenever a virtual environment is active, the PATH is temporarily modified such that python means the Python installation of that environment. It's quite convenient, really. You might be able to tell your IDEs to use py instead of a specific Python installation, and it might even be helpful to do so. I don't know. I don't use one.

我在这方面也遇到了问题，Windows在双击或cmd(命令提示符)时无法识别Python或Anaconda。

问题:无法在Windows中的“python”cmd中导入库。相反，Windows的“python”cmd将用户带到他们不想去的地方。 问题原因:在Windows“环境变量”中，Windows在“%USERPROFILE%\AppData\Local\Microsoft\WindowsApps”目录中添加了python.exe和python3.exe(我不知道这些链接到哪里)。

解决方案:我尝试删除WindowsApp目录中的python*.exe文件，但Windows不允许，所以我打开了“%USERPROFILE%\AppData\Local\Microsoft\WindowsApps”目录中的命令提示符，并键入:

del python.exe
del python3.exe

然后我创建了一个环境变量，链接到已安装的Python解释器链接。在我的例子中，它是C:\Anaconda3;C:\Anaconda3\脚本，以及其他一些良好的措施。

我把一个powershell片段放在一起，它重新排序了WindowsApps和Python文件夹，所以Python是第一个。以管理员身份运行:

$appsFld="$env:USERPROFILE\AppData\Local\Microsoft\WindowsApps"; 
$pyPath=(Resolve-Path "$env:USERPROFILE\AppData\Local\Programs\Python\Python*\")
$Env:Path = (($Env:Path.Split(';') | Where-Object { $_ -ne "$appsFld" }) -join ';'); 
$Env:Path = (($Env:Path.Split(';') | Where-Object { $_ -ne "$pyPath" }) -join ';'); 
$Env:Path += ";$pyPath";
$Env:Path +=";$appsFld";
[Environment]::SetEnvironmentVariable("PATH", "$Env:Path", "Machine")

然后我可以很好地运行python:

> python
Python 3.10.7 (tags/v3.10.7:6cc6b13, Sep  5 2022, 14:08:36) [MSC v.1933 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit