刚接触Webform的人，十有八九会在Visual Studio里拖控件拖得挺开心，然后点下F5，页面出来了，输入框、按钮、标签全在。但接下来呢？点按钮，页面刷新，数据没了——这几乎是每个新手都会踩的坑。Webform这套东西，说简单也简单，说坑多也真不少。

先说说它到底是什么。Webform是ASP.NET早期的一套页面开发模型，核心思路是把HTML界面和后台逻辑绑在一起，用服务器控件来生成最终发给浏览器的HTML。你在.aspx文件里写<asp:TextBox ID="txtName" runat="server" />，运行时它会被翻译成普通的<input type="text">。这个“翻译”过程由框架自动完成，省了你手写HTML的功夫。

但省事是有代价的。Webform最让人头疼的就是ViewState。你随便打开一个Webform页面，查看源代码，会看到一堆乱码似的隐藏字段，那就是ViewState。它的作用是记住控件状态，让页面在PostBack之后还能恢复之前的值。听起来挺贴心对吧？问题是这东西体积不小，页面稍微复杂点，ViewState就能膨胀到几十KB，全塞在页面里来回传。我见过一个老项目，一个列表页的ViewState占了将近200KB，加载慢得让人想砸键盘。

页面生命周期是另一个绕不过去的坎。Init、Load、PreRender、Render……每个阶段该干什么，不该干什么，搞混了就出bug。比如你在Page_Load里绑定数据，没加if(!IsPostBack)判断，那每次点按钮都会重新绑一遍，用户填的东西全被覆盖。这个错误太常见了，我几乎在每个新手写的代码里都见过。

控件事件模型也值得说一嘴。Webform的按钮点击事件看起来跟Winform一样直观，但底层其实是HTTP POST加上事件目标解析。你点一个按钮，整个页面回发到服务器，框架根据ViewState和控件树来判断是哪个控件触发了事件，然后调用对应的处理方法。这中间的开销不小，而且一旦控件树对不上——比如动态添加的控件在回发时没重建——事件就丢了，页面表现就像什么都没发生一样。

那Webform还能用吗？当然能。微软官方支持到.NET Framework 4.8，大量企业内网系统还在跑Webform。它的优势在于开发速度快，拖控件、写事件、跑起来，适合内部工具和快速原型。但如果你要做面向公众的、对性能和体验有要求的站点，Webform的短板就很明显了。MVC和后来的Blazor在这方面更合适。

学Webform，我的建议是别只停留在拖控件。搞明白ViewState的原理，理解页面生命周期的每个阶段，知道PostBack到底发生了什么。这些底层机制弄清楚了，遇到问题才不会抓瞎。否则你永远在“为什么我的数据没了”和“为什么事件不触发”之间反复横跳。工具本身没有好坏，关键是知道它怎么运转，什么时候该用，什么时候该换。