編按：本文綜合整理自 Windows Latest 原文實測報導 與 Hacker News 討論串，並加入 Siami 編輯部觀點與技術分析。
事件概要：點通知 ≠ 開信，要等 10 秒
Windows 11 內建兩個版本 Outlook：Outlook Classic（Win32 原生桌面 app）與新 Outlook（Microsoft 力推的接班人，本質是 WebView2 包裝的 Outlook.com 網頁）。兩者日常體驗差距越拉越大，最新一輪爭議聚焦在「點通知開信」這個最基本動作——
- Outlook Classic：點 Windows 11 通知 → 瞬間開啟對應郵件。
- 新 Outlook：點同一個通知 → 先載入完整收件匣 → 約 10 秒後才看到那封特定郵件。
更具黑色幽默的是，如果忽略通知、直接從開始選單打開 Outlook、自己點那封信，整個流程 5 秒內完成——比「點通知」還快一倍。
「五秒手動開 Outlook、自己點信；十秒等通知自動跳轉。這就算對 Microsoft 來說也太荒謬了。」—— Windows Latest 實測
這不是邊角案例，而是任何收到新信的人都會遇到的日常動作，也是郵件軟體最基本的功能承諾。
為什麼這件事重要：不是 bug，是 WebView2 架構的天花板
新 Outlook 是用 Microsoft Edge 的 WebView2 執行環境（Chromium 為基礎的渲染引擎）打造的。打開 Task Manager 會看到它一次跑 10 個獨立行程——WebView2 Manager、多個 WebView2 Utility、WebView2 GPU Process、WebView2 Service Worker 等，每個都吃一份記憶體，每個從休眠狀態喚醒都要時間。
| 量測指標 | 新 Outlook（WebView2） | Outlook Classic（Win32） | 差距 |
|---|---|---|---|
| 閒置 RAM | 490–636 MB | 117–148 MB | 約 4 倍 |
| 閒置 CPU | 約 4% | < 1% | 約 4 倍 |
| 點通知開信 | 約 10 秒 | 瞬間 | — |
| 行程數 | 10 個 | 1 個 | 10 倍 |
這是 web app 的本質限制：點通知 → 喚醒 web layer → 驗證 → 載入郵件 thread → 渲染，每一步都要經過瀏覽器引擎。Win32 原生的 Outlook Classic 把郵件本機快取，點下去就是開本地檔案，沒有「喚醒瀏覽器」這一段。
更具結構性意義的是：這不是 Microsoft 一個 app update 就能修的 bug。Windows Latest 去年 12 月曾報導 Microsoft 正在測試「Delayed Message Timing」API 來診斷 WebView2 app 性能問題，但截至目前 Outlook 通知仍沒用上。這意味著——短期內看不到修好的一天。
強制遷移的真實代價：使用者沒選過
Microsoft 在 2024 年高調慶祝新 Outlook 用戶成長，但這個成長很大一部分來自強制遷移——原本 Windows 上的輕量 UWP Mail / Calendar app 在 2024 年底正式關閉，使用者沒有選擇地被推到新 Outlook。
企業端也是類似劇本。Microsoft 原本計畫 2026 年 4 月強制企業從 Classic 切到新 Outlook，後來延到 2027 年 3 月——整整延一年，這件事本身就是承認「app 還沒準備好應付所有工作流」。
近半年新 Outlook 確實有進步：
- 2026 年 3 月更新：更好的資料夾搜尋、改進的共享信箱存取。
- 2026 年 5 月更新：自動對應（automap）行事曆支援——從 Classic 切過來不再掉共享行事曆。
- 2026 年 6 月更新：5 項新增功能，包含將在 8 月推出的「整合收件匣」（all-accounts inbox view）、改進的郵件合併、擴充的 .PST 支援。
- 2026 年 7 月更新：.PST 匯入加入行事曆項目與聯絡人（長期被詬病的痛點）。
但這些都是功能補完，不是性能補完。Microsoft 2026 年 6 月初列了 15 項「為什麼從 Classic 切過來」的生產力功能，但其中很多是 Classic 使用者早就有的——這個框架本身就透露了某種訊號。
Siami 觀點：WinUI 是唯一解，但至少還要 2 年
把 Outlook Classic 換成 WebView2 包裝不是 Microsoft 的偶然失誤，而是一個架構選擇的後果。他們想用 web 技術統一所有平台（Windows、Mac、Web、Mobile），代價是放棄原生 app 帶來的性能紅利。WhatsApp 走過同樣的路——把 WinUI 原生換成 WebView2 包裝後，閒置 RAM 直接跳到 1.2 GB；Notion、Slack、Discord 等桌面 app 也是 web engine 撐起來。
唯一真正解決性能問題的方法是回到原生——WinUI。Windows Latest 報導 Microsoft 已全力投入 WinUI，由前 MVP、現任 Developer Advocate Rudy Huyn 領軍籌組團隊，要做原生 Windows app。
這是對的方向，但郵件客戶端這種規模的 app 從 WebView2 重寫到 WinUI，工程量以年計。短期內（也就是 2026-2027 強制切換的時間窗），企業和使用者只能用「忍耐」或「不升級」撐著。
對重度依賴 Outlook 通知、需要快速回信的團隊（客服、銷售、危機處理），Outlook Classic 仍是更可靠的選擇——而且 Microsoft 已承諾支援到 2029 年 4 月，有將近 3 年的緩衝期。
數據解讀：三個被低估的訊號
- 「強制遷移的成長」不等於「產品成功」——2024 年的成長是 UWP 關閉的副作用，不是新 Outlook 體驗勝過 Classic 的證據。Microsoft 自己延後企業強制切換一年，就是承認了這點。
- WebView2 的瓶頸是結構性、不是過渡性——所有 web app 都有「喚醒慢、吃 RAM、CPU 高」的通病。新 Outlook 不會靠幾次功能更新翻盤，要等到 WinUI 原生版才有可能。
- Microsoft 對「web 化」的押注是全面性的，不是 Outlook 單一決策——WhatsApp、Notion、Slack、Discord、Teams 都在走同樣的路。這代表一般使用者的硬體升級壓力會持續上升，舊筆電、輕量筆電（如教育市場的入門機）會越來越難用。
從市場角度，這也是為什麼 2026 年起 **「native app 回歸」**成為 Hacker News 與 Reddit 上 r/programming 持續出現的討論主題——開發者與重度使用者已經體驗到 web 包裝的天花板。
目前的使用者選項
- 繼續用 Outlook Classic：可下載，支援到 2029 年 4 月。
- 改用替代品：Mozilla Thunderbird（原生、跨平台、開源）、eM Client（Windows 原生、有免費版）。
- 等待 WinUI 原生 Outlook：目前無明確時程，預估 2027–2028 才可能看到。
- 企業 IT：在 2027 年 3 月前評估關鍵工作流是否真能轉移到新 Outlook，無法轉的部門保留 Classic。
無論選擇哪一條路，「點通知 10 秒才看到信」這件事短期內不會修好。這是 WebView2 架構的結構性代價，不是 Microsoft 沒努力，而是 web engine 從設計上就比不過原生 app 的回應速度。
網友熱門留言 (5)