2003年我接手一个企业内网项目，客户要求把跑了五年的ASP系统迁到.NET平台。打开源码那一刻我愣住了——三千多行VBScript混着HTML，业务逻辑和页面渲染搅在一起，改一个查询条件得翻遍三个文件。这不是迁移，这是拆弹。

ASP和ASPX最直观的差别在文件结构。ASP页面里，<%和%>像钉子一样扎在HTML中间，服务器从上到下顺序执行，遇到数据库查询就卡在那里等结果。ASPX完全不同，后台代码放在.cs文件里，前台.aspx只负责展示。编译后的DLL跑在IIS里，第一次请求慢，后面快得飞起。我做过对比测试，同一个列表页，ASP每次刷新要重新解析VBScript，ASPX的页面生命周期虽然复杂，但ViewState和缓存机制让重复访问几乎瞬间响应。

迁移过程中最头疼的是Request和Response的处理方式。ASP里Request.Form("name")直接取值，ASPX里得用TextBox.Text或者Request.Form["name"]，方括号和圆括号的差别坑了我整整一个下午。还有那些用Include拼接的公共函数库，ASPX里得改成用户控件或者母版页。我记得有个日期格式化的函数，在ASP里用FormatDateTime就够了，搬到ASPX发现得引用Microsoft.VisualBasic命名空间，否则编译报错。

数据库访问层的改写更麻烦。ASP用ADODB.Connection和Recordset，写起来像流水账：打开连接、执行SQL、循环输出、关闭记录集、关闭连接。ASPX时代开始用SqlDataSource或者手写ADO.NET，SqlConnection、SqlCommand、SqlDataReader一套组合拳。好处是连接池管理自动了，坏处是代码量翻倍。我当时用代码生成器批量转换了七十多个页面，结果发现分页逻辑全乱了——ASP的AbsolutePage在ADO.NET里对应的是DataAdapter.Fill的起始索引和最大记录数，参数顺序还容易搞反。

ViewState是个让人又爱又恨的东西。ASP没有状态保持，每次回发都得自己用隐藏域或者Session存数据。ASPX自动把控件状态塞进__VIEWSTATE隐藏字段，页面体积暴涨。有个客户抱怨迁移后页面变慢，我抓包一看，ViewState占了80KB。后来禁用了一部分控件的EnableViewState，又用Session存大数据集，才算平衡了性能和便利。

事件模型的变化需要思维转换。ASP是线性脚本，按钮点击就是表单提交到某个URL。ASPX把点击变成服务端事件，Page_Load先跑，然后才是Button_Click。我见过不少新手在Page_Load里绑定数据，结果每次回发都重新绑定，把用户输入冲掉了。正确做法是用IsPostBack判断，这个坑几乎每个从ASP转过来的人都踩过。

配置方式也变了。ASP的数据库连接串硬编码在Global.asa或者每个页面顶部，改一次得全局搜索替换。ASPX用web.config，connectionStrings节点集中管理。加密连接串用aspnet_regiis.exe，虽然命令行参数难记，但比明文安全多了。

说句实在话，ASP转ASPX不是简单的语法替换。VBScript到C#的类型系统、页面生命周期、状态管理、编译模型，每一样都得重新学。我那个项目最后花了四个月，重写了六成代码，剩下四成靠包装COM组件勉强跑起来。但迁移完成后，部署变成复制DLL，调试能打断点，代码终于能分图层了。值不值？看系统还要活几年。如果只是再跑半年就报废，别折腾；如果打算再用五年，趁早转。

现在偶尔还有人问我ASP的问题，我一般建议直接上ASP.NET Core。ASPX本身也在被MVC和Blazor替代，技术栈这东西，追新不一定对，但停在原地肯定会被拖死。