Copilot Studio 換上 .NET 10 WASM 後更快了
Copilot Studio 把瀏覽器端 WebAssembly 引擎升到 .NET 10，帶來更快執行、較少部署雜活，還公開了實測數字。
Copilot Studio 把瀏覽器端 WebAssembly 引擎升到 .NET 10，執行速度變快，部署流程也少了幾段手工處理。
說真的，這種升級很實在。Microsoft 把 .NET 10 用到 Copilot Studio 的瀏覽器端 WebAssembly 引擎上，而且已經上線到正式環境。這代表 C# 直接跑在瀏覽器裡，啟動時間、下載大小、快取處理，都會直接影響使用者手感。
官方還丟出幾個很具體的數字。套件體積約增加 15%，第一次 AOT 呼叫快了約 20%，之後的 warm call 也快了約 5%。對開發者來說，這種數字比空話有用多了，因為它直接反映出取捨。
| 指標 | .NET 8 | .NET 10 |
|---|---|---|
| JIT 與 AOT 共用檔案數 | 59 | 22 |
| 套件大小變化 | 基準 | 約增加 15% |
| 第一次呼叫執行 | 基準 | 約快 20% |
| 後續呼叫執行 | 基準 | 約快 5% |
| 快速區網 AOT 下載 | 基準 | 約慢 200 毫秒 |
| 4G 網路 AOT 下載 | 基準 | 約慢 5 秒 |
這次升級到底改了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這次遷移其實很單純。根據 .NET Blog 的說法，Copilot Studio 團隊主要就是改專案目標框架，然後確認相依套件都能相容。講白了，就是把專案從 .NET 8 換到 .NET 10，再重建、上線。
這種做法很重要，因為 WebAssembly 專案很容易越做越肥。你一旦自己寫了快取清理、檔名雜湊、完整性驗證，下一次框架升級就可能又要補一堆補丁。Copilot Studio 這次的做法，是盡量吃進 .NET 10 的預設能力，少背自己維護的包袱。
我覺得這才是重點。很多團隊在意效能，卻忽略部署成本。結果效能只贏一點點，維運卻多一倍。Copilot Studio 的案例剛好反過來，它把一些手工流程交給框架處理了。
- 原本就是跑在 .NET 8。
- 新版已經正式上線。
- 原有快取邏輯仍然保留。
- 沒有重寫整個應用架構。
自動指紋化，少寫一堆部署雜活
.NET 10 對 WebAssembly 最有感的改動之一，是發佈資產自動 fingerprinting。白話一點，就是建置系統會自動在檔名裡加上唯一識別，快取更新和完整性檢查就不用自己拼命補腳本。
在舊流程裡，Copilot Studio 需要先讀發佈清單，再把檔案改成 SHA256 雜湊名稱，最後還要從 JavaScript 傳完整性資料去載入資源。這些事不是不能做，但很煩，而且很容易壞。升到 .NET 10 之後，這些步驟少了很多。
Microsoft 的 .NET WebAssembly runtime 也把這套流程整合進去。資源可以直接載入，檔名會自動指紋化，完整性驗證也交給平台處理。這種事看起來不起眼，但對長期維護很有差。
“Moving an existing .NET 8 WASM application to .NET 10 is largely a matter of updating the target framework in the .csproj files and ensuring all dependencies are compatible with the new version.” — Daniel Roth, Principal Product Manager, Microsoft
這句話很直白，也很有份量。它的意思是，框架開始把原本要靠團隊自己補的東西收回去。你少寫幾段自訂腳本，日後少踩幾次雷。
另外還有一個小細節。若你把 .NET WASM runtime 放進 WebWorker，初始化時要設 dotnetSidecar = true。這種設定看起來瑣碎，但常常就是你卡住的地方。
AOT 變更，重點其實不是變大一點
另一個值得注意的改動，是 WasmStripILAfterAOT 在 AOT 建置下預設開啟。意思很簡單。方法一旦先編譯成 WebAssembly，原本的 IL 在執行時就不需要了，所以 .NET 10 會自動把它剝掉。
Copilot Studio 用的是混合策略。JIT 先讓使用者快速互動，AOT 再在背景處理比較重的工作。這樣做的好處很明顯，就是先讓介面動起來，再慢慢把重活接上去。使用者不會傻等整包 AOT 下載完。
這裡的數字很值得看。JIT 和 AOT 共用的檔案數，從 .NET 8 的 59 個降到 .NET 10 的 22 個。這代表重複內容少了，分工更清楚，但也讓套件體積增加一些。
- 共用檔案數從 59 降到 22。
- 套件體積約增加 15%。
- 第一次呼叫約快 20%。
- 後續呼叫約快 5%。
如果只看下載時間，這看起來像是退步。但要放在使用情境裡看。Microsoft 提到，在快速區網上，AOT 下載大約慢 200 毫秒；在 4G 網路上，大約慢 5 秒。可是在這段時間裡，使用者已經可以先操作 JIT 版內容了。
所以這不是單純比大小。這是在比體感。對桌機使用者來說，背景多幾秒通常還能接受。對行動網路使用者來說，就要更仔細評估，但至少你拿到的是更快的執行速度。
這跟其他 WebAssembly 專案相比怎樣
如果拿一般 Blazor 或 WebAssembly 專案來看，Copilot Studio 的做法很像一個成熟團隊該做的選擇。它不是追求最小下載，而是把部署複雜度和執行速度一起算進去。這才符合真實產品，而不是 demo。
很多團隊卡在自訂資產流程。你可能有自己的檔名雜湊、完整性驗證、CDN 快取規則，甚至還有一堆 shell script。這些東西一旦散落在 pipeline 裡，升版就會變成考古現場。Blazor WebAssembly 部署文件 一直都在提醒這件事：部署越標準化，維護成本越低。
再看競品思路。像 Emscripten 路線偏向把 C++ 生態搬進瀏覽器。WebAssembly 本身也不是只服務 .NET。可是 .NET 10 的優勢在於，它把常見的資產處理收進框架，讓 .NET 團隊少寫很多周邊邏輯。
- .NET 10：自動 fingerprinting。
- 舊流程：手工雜湊與完整性檢查。
- JIT 先上，AOT 後補。
- 適合需要互動優先的產品。
如果你是做內部工具，這種差異可能更明顯。內部工具常常要求快速上線，也常常沒人想維護一堆自訂腳本。這時候，框架內建能力就很香，因為它少掉很多人肉維護。
如果你是做面向大量行動使用者的產品，就要更小心。4G 多出 5 秒，不是小數字。你得自己量測，不能只看官方 benchmark。這點我會講得很直接，因為很多團隊最愛拿別人的數字當自己的結論。
這次升級透露的產業方向
這件事其實在講一個很現實的方向。WebAssembly 不再只是「能跑就好」，而是開始講求可維護、可部署、可長期迭代。框架如果能幫你處理資產命名、完整性驗證、AOT 剝離，團隊就能把時間花在功能本身。
對 Microsoft 來說，Copilot Studio 是很好的示範案例。它不是小玩具，而是實際產品。既然正式環境都能從 .NET 8 升到 .NET 10，代表這套路線已經夠穩，至少對某些工作負載是這樣。
更大的意義是，這會影響其他做 Blazor、WebAssembly、甚至內部平台的團隊。你如果還在維護自訂 hash 腳本、手動 integrity 檢查，現在就該拿 staging 環境試一次 .NET 10。別等到下一次大升版才發現自己欠一堆技術債。
接下來該怎麼看
我會把這次更新解讀成一個訊號。未來做 .NET WebAssembly 專案，標準化部署流程會比自己造輪子更重要。效能當然要看，但維護成本也要一起算，不然你只是把問題往後丟。
如果你手上有 Blazor 或其他 WASM 專案，建議先做兩件事。第一，升到 net10.0 測試。第二，量一下你自己的下載時間、第一次互動時間、後續呼叫時間。別只看平均值，因為行動網路和桌機的差很多。
講白了，這種升級最怕紙上談兵。你應該先在 staging 跑一輪，確認資產 fingerprinting、AOT 行為、WebWorker 初始化都正常，再決定要不要全面切換。這樣比較務實，也比較不會翻車。