應用程式執行別名怎麼關|Python 跳 Store 解法

文章屬性:疑難排除
適用系統:Windows 11(全版本)、Windows 10 1709 build 16299 以上
難易度 / 耗時:入門 / 約 10 分鐘
核心結論:輸入 python 卻跳出 Microsoft Store,不是 Python 沒裝好,而是「應用程式執行別名」在 PATH 裡排得比你安裝的 Python 更前面、先被系統命中。
適用對象:在命令提示字元或 PowerShell 打指令,卻被系統轉去 Microsoft Store 商店頁的人

📌 快速答案

一句話答案:應用程式執行別名是 Windows 給打包應用程式註冊的指令名稱,python 跳 Microsoft Store 就是別名先被命中,到「設定 → 應用程式 → 進階應用程式設定 → 應用程式執行別名」把 Python 那幾條關掉即可。

🧰 開始前的準備

適用系統:Windows 11 全版本;Windows 10 需 1709(build 16299)以上,這是 AppExecutionAlias 擴充的最低系統需求
權限需求:一般使用者即可(別名是每位使用者各自的設定,不需要系統管理員)
需要工具:「設定」App、命令提示字元或 PowerShell(用 where 指令診斷)
預計耗時:約 10 分鐘

🔍 症狀描述與錯誤訊息

先講結論:這個症狀幾乎不是安裝失敗,是指令被攔截。

你從 python.org 下載安裝檔、一路按下一步裝完 Python,關掉視窗、重開一個 PowerShell,滿懷信心打下 python,結果畫面沒有出現熟悉的 >>> 互動提示字元,而是 Microsoft Store 直接跳出來,停在 Python 的商店頁面等你按「取得」。

有些情境更難察覺,終端機只回一行:

Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases.

這行訊息其實已經把答案講完了——它叫你去關掉一個「shortcut(捷徑)」,而那個捷徑的正式名稱,就是本文要拆解的應用程式執行別名(App Execution Alias)。

同一個症狀還有幾種變形,都源自同一個機制:

打 python 跳 Store,但打 py 卻正常進得去 Python
python --version 沒有任何輸出、也不報錯,直接跳回提示字元
排程或批次檔裡的 python script.py 在背景執行時安靜地失敗,查不到錯誤
VS Code、Git Bash 找得到 Python,單獨開 PowerShell 卻找不到

🔎 問題根因

直接結論:應用程式執行別名是 Windows 為「打包應用程式」(MSIX / 市集應用程式)註冊的指令名稱,系統會在你的使用者 PATH 裡放一個同名的 stub 檔;當這個 stub 排在你安裝的 Python 前面,python 就永遠先命中它。

這個機制本身不是 bug,而是微軟從 Windows 10 1709 開始提供的正式功能。市集應用程式被裝在受保護的 WindowsApps 資料夾裡,路徑帶著一長串套件識別碼,沒有人想在終端機手打;於是微軟讓開發者在套件資訊清單(package manifest)裡宣告一個 AppExecutionAlias 擴充,把「我這個 App 想被叫做 xxx.exe」登記進系統。使用者之後在任何終端機打那個名字,系統就會把它導向真正的套件。

依官方結構描述,這條別名有幾個硬性限制:名稱是 1 到 256 個字元、必須以 .exe 結尾,而且不能含有 <、>、:、"、/、\、|、?、* 這些字元。開發者還可以用 Subsystem 屬性宣告它是 console(主控台)還是 windows(視窗)程式——這解釋了為什麼有些別名會乖乖在原本的終端機視窗裡執行,有些則會另外彈出一個視窗。

Python 的情況特別容易踩雷,是因為在乾淨安裝的 Windows 上,python.exe 與 python3.exe 這兩個名字預設就掛著指向 Microsoft Store 版 Python 的別名。即使你根本沒裝過任何 Store 版 Python,這兩條別名仍然存在,它們的任務就是在你打 python 時把你送去商店裝一份。這是「找不到指令」的體貼設計,但對已經自己裝好 Python 的人來說,就變成了攔路石。

🔬 底層機制:這個「捷徑」到底放在哪一層?

要理解為什麼關掉別名就會好,得先看清楚系統找一個指令的順序。

當你在終端機輸入 python 並按下 Enter,Windows 不會去猜你想要哪一個 Python,它只做一件很機械的事:依照 PATH 環境變數由前往後,逐個資料夾找有沒有叫 python.exe 的東西,找到第一個就執行,然後停止。

關鍵就在於別名 stub 被放在哪裡。依 Python 官方文件的說明,這些指令捷徑位於 %UserProfile%\AppData\Local\Microsoft\WindowsApps,而作業系統預設就會把這個路徑加進 PATH 一次,位置排在其他使用者路徑之後;官方同時提醒,如果這一筆被刪掉,靠別名運作的指令就再也找不到了。

打 python 為什麼會跳 Microsoft Store 的 PATH 尋找順序流程圖

實務上的衝突長這樣:你安裝 Python 時如果沒有勾選「Add Python to PATH」,你的 Python 路徑根本沒進 PATH,WindowsApps 這一筆自然成為唯一命中的候選;就算你事後手動補上 Python 路徑,只要它被加在 WindowsApps 後面,別名還是先被命中。這也是為什麼「我明明裝好了」跟「它明明跳商店」可以同時成立。

另一個少有人提的層次是:微軟也允許打包版應用程式反過來「接管」同名的傳統執行檔。做法是在 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options 底下,以執行檔名建立子機碼並設定 AppExecutionAliasRedirect,系統就會改去啟動對應的打包版應用程式。這是給軟體開發者用的機制,一般使用者不需要動它——本文的所有解法都不必碰登錄檔,提出來只是要說明:別名不是單純的捷徑,它是有系統層轉導設計的一整套機制。

🛠️ 解決方案

⚠️ 動手前先做兩件事:①把 PATH 現值先備份下來——在 PowerShell 執行 $env:Path -split ';' 把輸出複製到記事本存檔,或在「環境變數」視窗把「Path」內容整段複製起來;②確認你手上這台不是公司或學校的受管控電腦。
停止條件(符合任一請先停手):不確定自己裝的是哪一版 Python、系統為公司/學校受 IT 管控且你沒有授權、指令輸出與本文描述明顯不符。這三種情況請先找 IT 或先做完系統還原點再繼續。

方法一:關掉 Python 的執行別名(成功率最高、最該先做)

這是官方文件本身就指出的入口。Windows 11 走「設定 → 應用程式 → 進階應用程式設定 → 應用程式執行別名」;更快的方式是直接在開始功能表搜尋「管理應用程式執行別名」(英文介面為 Manage app execution aliases),Python 官方的疑難排解表格用的就是這條路徑。

進去之後你會看到一整排開關,把名稱為 python.exe 與 python3.exe、來源標示為「應用程式安裝程式」或 Store 版 Python 的兩條切成「關閉」。如果你也用得到視窗版,順手檢查 pythonw.exe、pyw.exe 這兩條是否一致——官方排錯建議特別提醒這幾條要一起看,否則會出現 python 跟 pythonw 跑到不同執行環境的怪狀況。

關閉後請關掉所有終端機視窗再重開。PATH 與別名狀態是在行程啟動時讀取的,舊視窗不會自己更新,這一步沒做就會誤判「關了也沒用」。

方法二:把 Python 路徑排到 WindowsApps 前面

如果你的 Python 是自己安裝的、而且你想保留別名(例如你其實有在用 Store 版),那就改動順序:開始功能表搜尋「編輯系統環境變數」→「環境變數」→ 在使用者變數的 Path 裡,把你的 Python 安裝路徑(以及其下的 Scripts 資料夾)用「上移」按鈕移到 %USERPROFILE%\AppData\Local\Microsoft\WindowsApps 之上。

最省事的替代作法是重跑一次 Python 安裝程式,選「Modify」並勾選加入 PATH 的選項,由安裝程式處理順序。不要把 WindowsApps 那一行刪掉——依官方說明,那是所有別名指令的共同入口,刪了會連帶影響其他靠別名運作的程式。

方法三:改用官方現行的 Python Install Manager

2026 年的 Python 官方安裝方式已經轉向 Python Install Manager,它可以從 Microsoft Store 或 python.org 下載,兩邊是同一份東西。它本身就是靠執行別名提供 python、py、pymanager 這幾個指令,所以官方的排錯建議反過來是:確認「Python (default)」的別名是開啟的;若指令仍然失效,把它停用再重新啟用一次,以重新整理該指令。

這聽起來跟方法一矛盾,其實不然——差別在於「那條別名指向誰」。指向 Store 安裝頁 = 你要關掉;指向你已安裝的 Python Install Manager = 你要留著。先分清楚自己屬於哪一種,再決定開或關,是這題最關鍵的判斷點。

✅ 驗證修復結果

改完之後,不要只看 python 有沒有進去,要看「它進的是哪一個」。在新開的終端機執行:

where python

這個指令會把 PATH 中所有同名命中依序列出來,第一行就是你真正會執行到的那一個。修好之後,第一行應該是你的實際安裝路徑(例如 C:\Users\你\AppData\Local\Programs\Python\Python313\python.exe);如果第一行仍然落在 ...\Microsoft\WindowsApps\python.exe,代表別名沒關成功,或是關了但終端機沒重開。

接著再確認版本與模組路徑對得起來:

python --version

再進一步確認它到底是磁碟上的哪一支:先執行 python 進到 >>> 提示字元,輸入 import sys 換行後再輸入 sys.executable,畫面會印出目前這個直譯器的完整路徑。

這個路徑必須和 where python 第一行一致。兩者不一致,通常代表你同時裝了多套 Python,別名只是把問題掀開而已。

🔙 萬一翻車:回退步驟

關了別名之後,其他指令壞掉:回到同一個「應用程式執行別名」頁面,把剛才關掉的開關切回「開啟」即可。這個設定是純粹的開/關狀態,不會刪除任何檔案,切回去就復原。
編輯 PATH 之後終端機一堆指令找不到:用先前備份的 PATH 內容整段貼回「環境變數」視窗的 Path 欄位;如果沒備份,至少要確認 %SystemRoot%\system32、%SystemRoot%、%USERPROFILE%\AppData\Local\Microsoft\WindowsApps 這幾筆還在。
完全搞不清楚現在是什麼狀態:最保險的順序是——先把所有 Python 相關別名切回預設的開啟、把 PATH 還原、重開機,回到原點之後再從方法一重做一次。

💡 總結:預防再次發生

站長我自己踩過最久的一次,是在一台交接來的機器上除錯排程腳本:手動執行 python backup.py 完全正常,一掛到工作排程器就靜悄悄地什麼都沒發生。查了半天才發現,排程用的帳號跟我登入的帳號不同,而執行別名是「每個使用者各自一份」的設定——我這個帳號關掉了,那個服務帳號沒關。這件事給我的教訓很直接:遇到「手動可以、自動不行」的指令問題,先查 where,不要先懷疑程式。

要避免再遇到,平常可以養成三個習慣:

裝 Python(或任何 CLI 工具)時,養成勾選加入 PATH 的習慣,並在裝完立刻開新終端機跑一次 where,確認命中的是你要的那個。
腳本與排程一律寫絕對路徑,例如直接指定 C:\Python313\python.exe,不要依賴 PATH 解析——這一招同時免疫別名、多版本與帳號差異三種問題。
記得別名不只 Python。它是 Windows 給所有打包應用程式的通用機制,Windows 11 的記事本、winget、Windows 終端機等都靠它提供指令名稱;哪天遇到「某個指令跑起來不是我要的那個程式」,先想到這一頁,通常可以少繞很多路。

順帶一提,如果你的目的其實是在 Windows 上跑 Linux 那套工具鏈,與其跟 Windows 的 PATH 搏鬥,直接用 WSL 建一個 Linux 環境往往更省事;而如果你是重灌後要一次把開發工具裝回來,用 WinGet 做軟體部署程式碼化可以順便把 PATH 的問題一起處理掉。至於前面提到的排程踩雷,設定細節可以參考 Windows 工作排程器教學。

❓ 常見問題

Q:關掉應用程式執行別名,會不會影響到其他程式?

只會影響「用那個名字叫出來的指令」。別名是逐條開關,你關掉 python.exe 這一條,就只是讓 python 這個名字不再導向 Store 版 Python,其他別名與程式本身都不受影響。官方也把「在設定的應用程式執行別名頁面停用該項目」列為使用者關閉轉導的正常做法之一。

Q:我找不到「進階應用程式設定」怎麼辦?

直接在「設定」右上角的搜尋框輸入「執行別名」,或在開始功能表搜尋「管理應用程式執行別名」。不同 Windows 版本的選單層級略有差異,但搜尋一定找得到;Windows 10 上一般位於「設定 → 應用程式 → 應用程式與功能 → 應用程式執行別名」,層級比 Windows 11 少一層。

Q:為什麼 py 可以用,python 卻不行?

因為它們是兩條不同的指令來源。py 由 Python 啟動器/安裝管理員提供,python 則可能被別名攔截。官方的疑難排解表格把這兩者分開列,並建議兩邊的別名狀態要一起檢查。

Q:修完之後過一陣子又復發,是怎麼回事?

最常見的原因有兩個:一是 Windows 大版本更新或重新安裝 Store 版 Python 之後,別名被重新啟用;二是你在另一個使用者帳號下操作(別名是每個帳號各自的設定)。復發時直接重跑一次 where python,三十秒就能確認是不是同一個問題。

Q:直接把 WindowsApps 資料夾裡的 python.exe 刪掉行不行?

不建議。那個位置由系統管理,刪除或改名容易造成後續更新修復不了的狀態,而且它是所有別名指令共用的目錄;用設定頁面的開關關閉,是官方提供的正規做法,效果相同又可逆。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

uap5:AppExecutionAlias(套件資訊清單結構描述) — 2026-07-27 查證
uap5:ExecutionAlias(Alias 屬性限制與 Subsystem) — 2026-07-27 查證
Integrate your desktop app with Windows using packaging extensions(AppExecutionAlias 轉導與停用方式) — 2026-07-27 查證
Python 官方文件:Using Python on Windows(疑難排解與 WindowsApps 路徑) — 2026-07-27 查證

⚠️ 本文核心事實以第一級為準,第二級為補充。

📅 本文查證戳記:2026-07-27 依 Microsoft Learn 套件資訊清單結構描述與 Python 官方 Windows 使用文件撰寫。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。