在 Windows 上跑 Python 脚本，命令敲下去，脚本没跑起来。你以为装好了 Python，实际上系统里叫 python3 的那个东西，根本不是真的解释器。
现象
在命令行里执行：
> python3 script.py
有时会弹出应用商店窗口，有时直接失败或者行为诡异。进一步追查会看到 python3 指向的是一个奇怪的路径：
> where python3
C:\Users\<用户名>\AppData\Local\Microsoft\WindowsApps\python3.exe
注意这个 WindowsApps 目录——它不是你安装 Python 的地方，而是 Windows 应用商店的转发器（stub）。同时，系统里其实另有一个真正的解释器（比如来自某个 Python 发行版或 Conda），pip3 也来自那里，路径完全不同。
根因
这是 Windows 应用商店的占位 stub 在捣鬼。
Windows 10/11 里，系统会在用户的 WindowsApps 目录下预置几个"假"的可执行文件（python.exe、python3.exe 等）。它们并不是真的 Python，而是一个转发器：当你在没装 Python 的情况下敲 python3，它会把你引导到应用商店去安装 Python。
问题在于优先级：WindowsApps 目录默认在 PATH 环境变量里，而且往往排在前面。于是当你敲 python3 时，系统先命中了这个 stub，而不是你真正安装的解释器。你的脚本就这样被交给了"假的 python3"。
再叠加上一点点命名错位就更绕了：系统里真正装的解释器（比如 Miniconda / Anaconda 带来的）通常只登记了 python，不一定有 python3 这个别名，而 pip3 又来自它。于是出现"python 是真的、python3 是假的、pip3 是真的"这种让人头晕的组合。
解决
第一步，搞清楚命令名到底指向谁。 在 Windows 上用 where 把所有同名可执行文件列出来：
> where python
C:\Users\<用户名>\AppData\Local\Microsoft\WindowsApps\python.exe
C:\<发行版安装目录>\python.exe
> where python3
C:\Users\<用户名>\AppData\Local\Microsoft\WindowsApps\python3.exe
第一行落在 WindowsApps 里的那个，就是 stub。
第二步，不要用裸 python3，直接用真实解释器的绝对路径执行脚本和安装依赖：
> C:\<发行版安装目录>\python.exe script.py
> C:\<发行版安装目录>\python.exe -m pip install -r requirements.txt
用 -m pip 而不是单独的 pip，也能确保装进的是同一个解释器——避免"装到了 A 解释器、却用 B 解释器跑"的错位。
第三步（可选），把真解释器路径放到 PATH 前面。 如果你想继续用 python 这个名字，可以在系统环境变量里，把真实解释器所在目录移到 WindowsApps 之前；或者在"设置 → 应用 → 高级应用设置 → 应用执行别名"里，关掉 python.exe / python3.exe 这两个别名开关。关掉之后，系统就不会再把 python3 指向商店 stub 了。
延伸与预防
这条坑的普适教训是：搞清楚"这个命令名到底指向谁"，比记住命令名更重要。 一个命令在 PATH 里可能对应多个可执行文件，谁在前面谁生效；而"看起来一样"的命令，背后可能是完全不同的程序。
具体到日常实践：
- 新机器上先做一次体检：
where python/where python3/where pip，把每个名字解析到哪个路径看一遍，心里有底。 - 脚本和部署文档里一律写绝对路径，尤其是有多个 Python 环境时。绝对路径是唯一不会因为
PATH顺序而漂移的写法。 - 善用
-m：python -m pip、python -m venv这类写法，保证了"模块和解释器配套"，能避免大量"装在哪、跑在哪"的错位问题。 - 警惕"系统替身"。 不止 Python，有些命令在 Windows 上被系统预置了转发器。遇到"命令行为不符合预期"时，先
where一下看看是不是被替身抢了先。
一句话落地：别跟 python3 这个别名纠缠，认准那台机器上真正的解释器，用它的绝对路径。