本篇文章更新時間：2026/03/23
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
Windows 原生開發為何成了一團亂：從 Win32 到 WinUI 的迷走史
編輯前言：這是一篇來自 Windows Native App Development Is a Mess 的深度閱讀筆記。作者以一個「想要重溫童年寫小工具」的心情切入，卻意外揭開了 Windows 原生開發現況的混亂與停滯，讓我讀完真的深有同感。
核心觀點 (Key Takeaways)
- Windows 原生開發框架 25 年來持續推倒重來，導致功能不完整、碎片化嚴重。
- WinUI 3 仍無法獨立構建完整應用，大量場景仍需往下 P/Invoke 調 Win32。
- 在語言、打包、部署與 API 設計上，Microsoft 的策略反覆搖擺，讓原生開發者進退兩難。
深入解析
作者以一個簡單的黑屏工具 Display Blackout 作為切入點，卻在實作過程中處處撞牆。這支小工具需要的能力其實不複雜：列出顯示器資訊、顯示無邊框視窗、攔截快捷鍵、托盤圖示、開機啟動、儲存設定。然而，放到 Windows App SDK 與 WinUI 3 裡，這些基礎能力卻完全「不完整」。
作者點出一段非常有代表性的觀察：
"Even something as simple as automatically sizing your app window to its contents was lost somewhere along the way from WPF to WinUI 3."
這不只是功能缺失，而是 UI framework 代代重啟、每一代都不同，並且都不完整。從 Win32 → MFC → WinForms → WPF → WinRT → UWP → WinUI 3，每一次框架更替，都像是重新發明 Windows，而不是在穩固基礎上改良。
-
語言與 API 的錯位問題：
C# 在 Windows 的核心語言地位本該能配合平台演進，但作者指出一個令人難以置信的細節：C# 竟然無法表達 Win32 中「[optional, out]」這種基礎參數型別。這導致 CsWin32 要產生兩組 API 版本來彌補語言層級的缺陷。這段話令人印象深刻：
"What has the C# language team been doing for twenty years, that creating native observable classes never became a priority?"
-
部署與打包比想像中更痛苦：
即使使用 WinUI 3，也面臨選擇困境：C++ 太危險、C# 若用 framework-dependent 廣佈又會逼使用者下載最新 .NET、最終只能選 .NET AOT，結果是一個黑屏小工具編譯後達 9MB。而真正讓作者崩潰的是 MSIX：證書一年要 200–300 美元，而且無法免安裝上架 Microsoft Store（還會因「not offering unique lasting value」被退件）。
-
WinUI 3 自身的缺口：
作者點出最關鍵的比較表（節錄重點）： -
列舉顯示器資訊：勉強可行，但監聽變動仍需 P/Invoke。
-
無邊框視窗：部分可做，但非激活視窗一定要 P/Invoke。
-
全域快捷鍵：無，必須 P/Invoke。
-
托盤圖示與選單：完全不支援。
換句話說，WinUI 3 想成為新一代 Windows UI，但其能力連 Win32 的 70% 都還沒覆蓋。
筆者心得與啟發
讀完整篇文章，我覺得最殘酷的不是技術細節，而是作者揭露的某種「平台疲乏」。Windows 團隊像是逐步放棄了打造一個一致、可靠的原生開發體驗。連作者這樣技術背景深厚的 Windows 老用戶，都不得不說：
"why not Electron?"
坦白講，這段話讓我震撼，因為它反映了多數開發者的真實感受。當一個平台複雜、碎片化又缺乏回應時，大家自然會轉向更穩定、跨平台且社群活躍的選擇。
我自己的體悟是：
- Windows 原生技術已經累積了太多歷史包袱，要「再來一次」的代價太高。
- WinUI 3 是微軟難得嘗試統一現代 Windows 的機會，但目前明顯人力與策略投入不足。
- 如果你的應用需要跨平台、快速開發、容易部署，那 Electron 或 Tauri 其實早已是更現實的選擇。
或許，Windows 原生開發永遠都會是一條艱難、零碎、充滿坑洞的路。但至少，透過這篇文章，我們更清楚看到：問題不是開發者的選擇，而是平台整體的結構性失能。