ASP脚本避坑指南：17年老运维总结的5个致命语法细节

　　跟产品吵完第三轮，PM把需求文档甩在茶水间微波炉上——那台去年就坏掉的、转盘卡死在四十五度角的微波炉。我盯着门缝里漏出的蓝光，忽然想起去年春天，那个凌晨两点十七分的接口背锅局。DBA老周在监控大屏前蹲着啃冷包子，包子馅是白菜的，油顺着食指流到键盘F7键上。他指着屏幕右下角一个飘红的ASP响应时间曲线说：“你脚本里又没关cursor”，我说“我关了”，他说“你关的是rs.cursorlocation，不是rs.cursortype”，我说“都带cursor啊”，他抬头看了我三秒，把包子最后半口塞进嘴里，腮帮子鼓得像含了枚U盘。

　　第一个坑：Response.Write后跟Response.End。不是WriteLine，不是Write+End的组合技，就是Write完立刻End。我原以为这和C#里return差不多——干净利落。结果？IIS6不报错，IIS7报500但日志里没堆栈，IIS10直接吞掉整个response body，只留HTTP头。这个我敢打包票：去年春天那单，测试跑回归用的IE8虚拟机，页面空白，前端小张刷新八次后抓包发现Content-Length是零，而他写的alert("loaded")压根没触发。后来翻源码才发现，某个判断分支末尾写了Response.Write("ok") + Response.End——中间没换行，缩进粘在一起，像句错位的暗语。

　　咖啡杯上印的公司logo是歪的，左边缺了一小撇，像被谁用指甲盖刮过。上周五oncall手机震了一下，我没接，正蹲在服务器机柜后面查网线水晶头，左手还沾着三号机房那台老Dell的散热灰。震动停了，我看了一眼锁屏——是运维群弹窗，消息已折叠，只显示“…【紧急】订单导出接口崩了”。我没点开。因为我知道，崩的不是接口，是那个被前端硬塞进ASP页面的——type参数根本没校验，有人传了个null，Response.ContentType就被设成了空字符串，IIS就当你是想返回text/html，可下面紧接着是BinaryWrite，两套协议在内存里掐架，最后吐出十六进制乱码给浏览器。我们管这叫“协议窒息”。

　　第二个坑：Server.CreateObject("ADODB.Recordset")之后，必须显式Set rs = Nothing，不能只靠Session超时回收。我说不准是不是IIS6的COM对象池有记忆残留，还是某次热更新没清掉引用计数——反正去年春天那回，灰度开关只推了六台机器里的四台，剩下两台跑了十七小时没重启，第十八小时开始，所有新连接都卡在Open方法上，超时三十秒。DBA老周去杀进程，发现svchost.exe下面挂着三百七十二次调用，全是同一个clsid。我们后来用Process Explorer扒出来，每个线程都卡在CreateObject返回后的第一行：rs.Open sql, conn。没人动SQL，conn也没断，就是Open不动。后来我手动在Global.asa里加了个Application_OnEnd事件，里面遍历所有rs变量做Set … = Nothing——写完自己都觉得滑稽，像给拖拉机装自动泊车。

　　测试王工去倒了杯水，用的是那个印着歪logo的杯子。水烧开了，壶嘴冒白气，她没关火，就站在饮水机旁看我们争论。她说“要不……测下不带分页参数的请求？”没人理她。后来我们改完，她默默把那个带分页参数的curl命令贴进Postman——成功了。可第二天上午十点二十三分，订单中心发来截图：同样是这个接口，后台日志里多出一行“error 800a01a8”，错误描述是“对象必需为集合”，源头是那行for each item in rs——rs明明Open成功了，recordcount也大于零，for each却认不出它是个集合。查了两小时，发现rs.CursorType被悄悄设成adOpenForwardOnly，而adOpenForwardOnly在某些IIS补丁版本下，For Each语法糖会失效。不是bug，是微软的“优胜劣汰”——淘汰你不用adOpenStatic的地方。

文章配图，仅供参考

　　第四个坑：On Error Resume Next之后，Err.Number必须立刻检查。不是下一行，不是同一段代码块，是立刻。我们有个老同志习惯写成：On Error Resume Next / rs.Open … / If Err.Number 0 Then … / 执行别的逻辑。结果有一次，rs.Open其实成功了，但下面一句rs.MoveFirst失败了（因为游标位置不对），Err.Number变成-2147217887，而他判断Err.Number那段早过了。整个过程像一场无声的车祸——引擎还在转，方向盘却失灵了。这事发生时，我正看着监控大屏上一条无关曲线抖了一下，那是隔壁组的Redis慢查询报警，跳了两下就下去了，和我们毫无关系，但我盯着它看了整整四十秒。

　　第五个坑最贱：Response.Redirect后没加Response.End。我知道你们都会加，我也加，但去年春天那个凌晨，那个被产品逼着“先上线再修”的版本里，有个else分支写了Redirect，下面还跟了三行log写入——Response.WriteToLog("redirected")之类的。IIS照常执行，log写了，重定向也发了，浏览器跳走了，但服务端线程还在跑那三行。问题不在这儿。问题是，这三行里有一句Session("last_op")=Now()，它修改了Session状态，而SessionStateMode是InProc——结果另一个并行请求刚进来，SessionID撞上了，直接拿到一个时间戳格式错乱的值，后面所有日期比较全炸。这不是Redirect的问题，是Redirect之后你还想对Session动手，就像在电梯关门瞬间伸手拦门。

　　现在我改了习惯：看到Redirect就条件反射敲End，哪怕是在注释里写“// TODO: check session side effect”都不如直接End干净。至于剩下的两个坑——一个是Request.QueryString里的+号被当成空格解码，另一个是Server.HTMLEncode对中文双字节字符的截断，我懒得写了。手边这杯水快凉了，水面上浮着一小片茶叶梗，歪着，像那个logo。

　　今晚我打算把所有Response.Redirect改成Response.Status="302 Found" & vbCrLf & "Location: " & url & vbCrLf & vbCrLf，然后直接Response.End。不走封装函数，不走公共类，就裸写。写完推灰度，看那台微波炉门缝里的蓝光还闪不闪。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!