这个现象让我很是迷惑了一下，还以为是 Python 运行环境出了什么状况，但很快反应过来，从现象看，应该是 Windows 搞的鬼。
检查一下路径是否正常，果然：
- \$ where python
- C:\\Users\\yuhao\\AppData\\Local\\Microsoft\\WindowsApps\\python.exe
原理是系统自己搞了一个 Python.exe。如果从在资源管理器打开上述目录的话，会看到这里只有孤零零的几个 .exe 文件，且图标也不正常，并不是一个真正的、完整的 Python 运行环境。
那么问题来了，Windows 搞这些没有实际环境的 .exe 出来，用意何在？
从网上找到一些信息，原来从 Windows 10 2019 五月更新以来，微软试图把 Python 带到 Windows，至于具体做法，则是把 Python3 放到了自家的商店里面。而上面看到的 python.exe 是一个“假的” Python，它的唯一作用在于当系统没有找到 Python 的时候，自动跳转到微软商店去让我们下载。
以下是微软团队给出的说法：Who put Python in the Windows 10 May 2019 Update?
可能是担心这个新的功能导致一些兼容性方面的结果，微软又在系统设置里面添加了一个比较隐晦的功能。比起在层层叠叠的设置界面里找到它，更简单的方法是直接输入 app exec：
这样会打开设置的“应用程序别名”界面。这里我们会看到系统认为 python.exe 和 python3.exe 都只是安装程序的别称，不过我们也可以选择把它们关闭。这样当我们再运行 python 的时候，就会显示“找不到程序”的标准提示。实际上，Windows 是把上述 .exe 文件偷偷备份到其他地方了。
很多程序员（包括我）很可能都是按照标准的方式从官方下载安装 Python 执行文件。如果在安装过程中选择了“添加到系统环境变量”的话，那么标准 Python 会注册到系统 PATH 变量，而前面所述的 WindowsApps 目录则是 Windows 添加到用户 PATH 变量的。按照 Windows 系统的规则，PATH 环境变量是系统设置先于用户设置，所以如果安装了标准版 Python 的话，系统应该首先找到的是它，而不是应用商店版的 Python。后来我发现，之所以我的机器会出现上述问题，是因为系统设置有一点语法错误，修正以后再次测试，结果就正常了。
到此，我们已经理解了 Windows 自带的 Python 是怎么回事。微软这样做的初衷，应该是希望普通用户能更方便地用上 Python，这个想法无可厚非，但放到 Windows 应用商店这个设计思路是否合理，我还是有一些怀疑的。毕竟微软应用商店一直以来名声并不算太好，内容少、功能欠缺、速度慢，时不时发生一些恼人的小问题（比如 不知所云的 0x8000xxxx 错误）。而“应用程序别名”这个功能到底是解决了问题还是带来更多的困惑，我也持保留意见。
当我在网上查找关于该问题的信息时，也发现有其他用户同样受到该问题的困扰，比如：
- [Bug] Don't find python library from WindowsApps dir
- Microsoft Store installed python (3.7 - Windows 10) based virtualenvs cannot access pyd DLLs
目前，在 Windows 上面安装 Python 已经有很多不同的方式：
- 通过官方网站下载安装；
- 通过 Anaconda 集成软件包；
- 和 Visual Studio 一起安装；
- 通过 chocolatey 之类的第三方包管理；
- 通过 WSL 安装 Linux 版 Python；
- 通过 Windows Store 安装；
说实话，我认为太多不同的来源渠道会让环境问题变得更复杂，增加出错的可能，并且容易迷惑初学者。对于大多数程序员来说，建议大家还是按照最基本的方式，从官方下载并安装 Python。
