WebForms Core 的命名是故意的。CodeBehind 的介紹寫著，結構和命名會讓人想起以前的 Microsoft Web Forms。官方教學的結論也說，功能感覺相近，實作是另一套更有彈性的做法。要學會新的那套，得先知道舊的直覺從哪裡來，又是哪裡斷掉。

一頁應用程式，長在伺服器上

經典 ASP.NET Web Forms 把網頁做成 。你在設計工具裡放 、、，框架產生 與 。按鈕有 事件，事件處理常式寫在 code-behind。對許多人來說，這和 WinForms 幾乎是同一種心智模型：控制項、屬性、事件。

使用者按下按鈕時，瀏覽器把整個表單 POST 回同一支 URL。伺服器重建頁面物件，還原上一輪存下來的狀態，引發事件，再把完整 HTML 送回去。瀏覽器整頁替換。這就是 PostBack。

狀態要活過這一輪，靠的是 ViewState：一段藏在隱藏欄位裡的序列化資料。控制項樹一深，這個欄位就變大。你也比較難保證畫面上的 HTML 和自己手寫的標記一致，因為很多標籤是控制項渲染出來的。

HTTP 模組與處理常式掛在 。應用程式有一條固定的生命週期事件。這些都綁在 與 Windows 上的 .NET Framework。

它沒有跟著進 ASP.NET Core

ASP.NET Core 拿掉了 。管線改成 middleware，設定改成 與相依性注入，跨平台執行。微軟沒有提供「把 Web Forms 專案改個目標框架就能跑」的官方路徑。

Microsoft Learn 上的遷移建議可以收成三句：

  • 業務邏輯先從頁面拆出去，頁面技術才換得動。

  • 想保留「元件 + 事件」的手感，優先看 Blazor。

  • 大型站點用絞殺者模式：新站與舊站並存，一次搬一頁。Visual Studio 的升級助理可以用 YARP 把兩邊接在一起。

Blazor 的免費電子書《Blazor for ASP.NET Web Forms Developers》把元件、事件和單向綁定，逐項對回 Web Forms 的控制項與 PostBack。那是微軟給的對照。Web Forms 本身會隨著 .NET Framework 繼續存在於 Windows，只是它不是 .NET 10 的一部分。

WebForms Core 保留了哪一種感覺

Elanat 的做法不是把 類別搬過來。它保留的是這句工作方式：人在伺服器上決定畫面要怎麼變。

差在「變」的單位。舊模型重建控制項樹，再渲染整頁。新模型產生幾行指令，例如把某個 的字級改成 28 像素、把送出鈕停用、在表單末尾加一個 。瀏覽器已經握有 DOM，不需要再收一次整頁。

官方列出的差異，值得當成設計約束而不是口號：

  • 伺服器只產生協定文字，不在伺服器上組出整份新 DOM。

  • 不使用 ViewState，View 頁面的 HTML 由你掌控。

  • 送出資料走 AJAX，頁面本身不重新載入。

  • 可以沒有 View。一支靜態 HTML 也能對伺服器發請求。

  • 仍然可以呼叫 JavaScript。不做前端，是選項，不是封印。

同樣是「按按鈕之後伺服器決定結果」。左邊換掉整頁，右邊只改被點名的節點。

官方教學有一句容易誤讀：「沒有 PostBack 機制」。指的是沒有 Web Forms 那種整頁 PostBack 與 ViewState。WebFormsJS 仍然提供名為 的 JavaScript 函式，用來以 AJAX 送出表單。同名，不同機制。第 5 章會把這個函式拆開。

它比較像什麼

如果要用你已經會的東西來定位：它接近「伺服器渲染一小段操作腳本」，而不是第二個 React。你不描述虛擬 DOM，你描述對真實 DOM 的編輯動作：加標籤、設文字、設顏色、刪節點、綁事件。

頻寬上的好處來自這件事。一次成功的點擊，回應可能只有幾行：

[web-forms]
fs<form>=28px
bc<form>=violet
sd(btn_SetBodyValue)=1
nt<form>=h3
st<h3>=Welcome Nicolas!

瀏覽器不需要一份新的版面、一份新的腳本、一份新的隱藏欄位。代價是：你要會描述「改哪一個節點」。指錯節點，指令會作用在別的標籤上，而且不會有控制項樹在編譯期幫你擋下來。第 6 章就是在練這件事。