OpenSilver 3.2 讓 WPF 應用透過 .NET MAUI 跑到 iOS 與 Android，並沿用 XAML（宣告式 UI）與 C#（.NET 語言）大部分程式碼，同時也能走 WebAssembly（瀏覽器執行技術）這條線。（來源：OpenSilver 3.2 發佈資訊2024；來源：Microsoft .NET MAUI 文件2024）
- 同一套核心邏輯：C# 商業邏輯多半能留住
- UI 不用全砍重做：XAML 觀念延續，但要為觸控調一調
- 交付面變大：Windows、瀏覽器、iOS、Android 可以同時看
- 代價也要先吞下去：效能、版面、MAUI 生態成熟度都得評估
先把話講死：OpenSilver 3.2 在解決什麼痛
OpenSilver 3.2 的核心價值是把既有 WPF 技術資產接到 .NET MAUI 的跨平台宿主，減少「為了上手機而整套重寫」的成本，讓企業內部系統能延伸到 iOS、Android、macOS 與 Web。（來源：OpenSilver 3.2 發佈資訊2024）
你現在腦袋裡如果是：「我們那套 WPF 寫了十年，功能像怪獸一樣大，誰敢重寫？」對，講的就是這種情境。
重寫最麻煩的不是「寫不寫得出來」。是你寫出來之後，規格跟原本的行為對不對得起來、報表那個小數點到底要不要四捨五入、權限那顆按鈕誰能看到、每個部門都說自己是例外……那種磨人。很磨人。
講到例外我突然想到，很多公司其實不是缺技術，是缺「敢停下來整理需求的人」。然後就一路補洞補到天荒地老。好，拉回來。
把舊系統拉到新平台，真正貴的常常不是程式碼，是你不敢動的那堆規則。
OpenSilver 是什麼，不要把它想得太玄
OpenSilver 是一個開源框架，最早承接 Silverlight 的路線，主打用 .NET 與 XAML 把應用帶到瀏覽器（透過 WebAssembly）與更多環境；3.2 開始把「跑在 MAUI 裡」這件事做得更完整。（來源：OpenSilver 專案說明2024；來源：公開資訊，建議查證）
用生活比喻：你家有個老舊延長線（WPF 專案），插頭規格就是那樣。OpenSilver 有點像轉接頭，讓你可以把那條延長線插進「新的插座規格」（MAUI 的世界），然後插座後面通往 iOS、Android 那些地方。
但我也要嘮叨一句：轉接頭不會讓你家的電器瞬間變成最新款。它只是讓你先能用。能用很關鍵。
這裡有個常見誤會：以為「不用重寫」等於「不用改」。不對。UI 跟互動方式，總是要動一點點。你在桌機上靠滑鼠 hover 的東西，放到手機上就……沒有 hover 這件事了。
MAUI 在這裡扮演什麼角色
.NET MAUI 是 Microsoft 的跨平台 UI 框架，是 Xamarin.Forms 的延伸，目標是用單一程式碼基底輸出 Windows、macOS、iOS、Android；OpenSilver 3.2 的重點是把既有的 WPF 風格 UI/邏輯接進 MAUI 的宿主與部署管線。（來源：Microsoft .NET MAUI 文件2024）
你可以把 MAUI 想成：「官方鋪好的路」。打包、簽署、上架流程、平台專案結構，很多是它提供的。OpenSilver 這次就是把你熟的那套 XAML/C# 盡量帶上車。
我記得以前大家從 WPF 要跨到手機，常見路線是：UI 全改、框架全換、團隊要再學一輪。然後 PM 還會問：「那能不能下個月上線？」嗯。對。就這樣。
你會真的省到錢嗎，先看你欠的債是哪一種
OpenSilver 3.2 的「投資保護」主要發生在兩塊：保留既有 C# 商業邏輯與部分 XAML UI 結構，並用增量調整取代大規模重寫；但觸控 UX、效能與第三方控制項相容性仍需要專案評估。（來源：OpenSilver 3.2 發佈資訊2024；來源：Microsoft .NET MAUI 文件2024）
我先幫你分兩種債：
- 規則債：交易、審核、權限、稽核、報表邏輯那種，寫得很硬、也很難搬。這種如果能留住 C#，真的差很多。
- 介面債：桌機時代的密密麻麻、多欄位、多快捷鍵。搬到手機螢幕，會直接爆炸。你不改，使用者也用不了。
原文提到金融公司那種 2012 年做的交易看板，我覺得很典型：圖表多、資料流快、規則一堆。你把它延伸到 iPad 給外出的人用，價值很直觀。
但媽媽式提醒：你要先問「誰真的會在外面用？」不要為了跨平台而跨平台。手機上看盤跟桌機上看盤，節奏不一樣。這不是框架能替你想的。
跨平台不是把程式丟上去就算了，是把使用情境一起搬過去，搬得動才算數。
實作時最容易踩的坑，我先幫你把雷畫出來
把 WPF 風格應用帶到 iOS/Android 的主要風險集中在三點：效能行為差異、螢幕尺寸與觸控互動差異、以及 MAUI 與相關生態的成熟度；這些問題多半能用增量方式修正，但需要預留測試與調整時間。（來源：Microsoft .NET MAUI 文件2024；來源：公開資訊，建議查證）
1) 效能不是一句「會優化」就過了：桌機你可能靠 CPU 撐住，手機就不一定。還有動畫、列表、資料繫結，這些地方會放大差異。
2) UI 會被迫變「大顆」：按鈕要變大、間距要變大、字要能讀。你原本那種像 Excel 的密度，搬去手機會讓人眼睛痛。
3) 控制項與相容性：你公司如果用了很多第三方 WPF 控制項，先盤點。真的。不要等到最後一週才發現某個圖表在手機上行為不一樣。
講到盤點我就想到台灣很多團隊很愛「先做再說」，然後做到一半才開會問「咦那個授權怎麼算」。拜託，這種事早點問。
工具跟資料庫，我給你一個方向：MAUI 的平台打包、簽署、部署流程，官方文件寫得算完整，先把 Microsoft Learn 上的 .NET MAUI 文件翻一遍；OpenSilver 的 GitHub release notes 也要看，至少知道 3.2 到底新增什麼、限制什麼。（來源：Microsoft Learn 2024；來源：OpenSilver 專案資訊2024）
截圖就能用的自我檢查清單
把 WPF 專案導入 OpenSilver 3.2 與 .NET MAUI 之前，先用同一份清單檢查「可搬的部分」與「一定要改的部分」，可以大幅降低重工與踩雷機率。（來源：公開資訊，建議查證）
自我檢查清單：
- 程式碼資產：核心商業邏輯是否集中在 C# service / domain layer，而不是散在 UI code-behind？
- XAML 密度：畫面是不是靠大量 Grid、DockPanel、密集欄位撐起來？如果是，先挑 1–2 個關鍵流程做「手機版布局」試做。
- 互動方式：有沒有大量 hover、右鍵選單、快捷鍵？這些在觸控上要替代方案。
- 第三方控制項：列出所有 WPF 控制項供應商與版本，確認替代或相容策略。
- 效能指標：先定義你在意的指標（啟動時間、列表捲動 FPS、記憶體峰值），不要只講「順不順」。
- 測試策略：是否有自動化測試（至少是關鍵邏輯的單元測試）？沒有就先補一點，別硬上。
- 部署現實：iOS 簽署、上架、MDM 企業配發流程誰負責？Android 裝置型號碎片化怎麼驗？
- 使用者情境：你要解的真的是「外出使用」嗎？還是其實只要在瀏覽器跑得順就夠？
你先把「要不要搬」想清楚，再來談「怎麼搬」，不然只是把焦慮搬到別的平台。
我自己的看法比較偏保守：OpenSilver 3.2 這條路，適合「WPF 真的很大、規則很多、你不敢一次推倒」的團隊。你先做出一個能跑在 iOS/Android 的版本，讓業務或現場的人試用，然後再決定要不要繼續擴。
反過來，如果你本來就準備重做 UI、也準備換整個互動設計，那你選 Flutter、React Native，或直接重建一套 MAUI 介面，其實也不是罪。只是你要承認那是「重寫」，不要用「改版」騙自己。
我想問你一個很實際的：你手上的 WPF 系統，現在最卡的是「一定要上手機」？還是其實卡在部署、維運、或瀏覽器相容性？你最想先解的那個痛點，是哪一個？
