ASP脚本避坑指南：元数据工程师十年踩坑总结

　　改版上线翻车。凌晨三点十七分，我盯着屏幕右下角的系统时间，手指悬在键盘上方——不是因为犹豫，是左 Shift 键卡住了，按下去没弹起来，得用指甲往里顶一下才复位。这键盘跟了我四年，F12 键帽早磨没了，现在摸上去是平的。我切到 Chrome DevTools 的 Network tab，看着那个 /meta/asp/getSchema.asp 的响应时间从两百毫秒跳到三千一百毫秒，又跳回八百四十六，再崩成超时。我原以为是 IIS 连接池溢出，结果查日志发现是 ASP 的 Server.CreateObject("ADODB.Recordset") 在 open 时，偷偷把元数据表名拼进了 SQL 字符串，连引号都没转义。那个表名叫 [sys].[dm_exec_describe_first_result_set]——带中括号、带点、带下划线，ASP 用 & 拼接完直接喂给 Execute()，没报错，只返回空集。空集？它连字段数都懒得数。我们测试环境跑得好好的，因为测试库的 sys 表是只读快照，没有这个动态视图。生产库有。它就安静地、优雅地、一毛不拔地返回 null。优胜劣汰？对，劣的活下来了，优的被当垃圾回收了。

文章配图，仅供参考

　　旁边小王去茶水间倒水，路过我工位时看了眼屏幕，说“又挂 ASP？”我说嗯，他没接话，但我知道他想说什么——他去年重写了三个 ASP 脚本的元数据提取逻辑，全改成 C# Web API 调后端服务，接口契约文档写得比他娃出生证明还厚。可 PM 昨天在站会上说：“ASP 现在跑着的，就别动；只要它还能吐出 Schema JSON，我们就当它是活的。”她边说边把 iPad 上的 Axure 原型往下拉，拉到第三屏，点开一个叫“元数据血缘图”的交互，里面写着“点击节点 → 弹窗展示上游字段来源（支持 ASP/SQL Server/Oracle）”。支持。呵。我敢打包票，那个“ASP”标签底下写的全是注释掉的 VBScript 片段，连 Response.Write 都被 / / 包着。PM 不知道，测试不知道，后端老张更不知道——他只管 JDBC URL 和连接池最大值。他上周还问我：“你那边是不是把 schema name 做成变量传进来了？我这儿 log 里看见一堆 @schemaName=‘sys’。”我没吭声。那根本不是变量，那是硬编码在 response.write “<schema name=‘” & request.querystring(“db”) & “’>” 里的字符串拼接。@schemaName 是他以为的，实际是 &request.querystring(“db”) 的返回值，而 request.querystring(“db”) 是从前端一个隐藏 input 里抓的，input value 是 。那个 sys，是从一个 dropdown 选出来的。dropdown 的 option.value 写的是 "sys"，option.text 写的是 “系统元数据表”。没人改过它。没人动过。

　　桌上那份麻辣烫的汤洒了一滴，在键盘右侧 ESC 键旁边晕开一小片油光，反着光。我抬手擦，蹭到 Shift 键残留的胶感。其实 ASP 最坑的不是语法老，是它把错误藏得太深：Server.ScriptTimeout 设成 300 秒？没用。脚本卡在 ADO 的 .Open() 上，超时不抛异常，只让整个请求线程吊死，等 IIS 自己杀进程。你抓不到堆栈，看不到行号，只能看到 w3wp.exe 的 CPU 占用突然飙到 98%，然后所有其他 ASP 页面全变成白屏。我们上个月在生产环境搞了一次“静默重启”，就是半夜三点半手动停启 IIS 服务，为的就是清掉那些吊死的线程。没人敢动代码。不是怕改错，是怕改完之后连静默重启都救不回来。后端老张说：“你不如直接写个定时任务，每五分钟 curl 一次你的 ASP 页面，让它 keep alive。”我说好。他走了。我忘了执行。第二天早上九点二十三分，血缘图的上游链路断了十七分钟，因为 /meta/asp/getSchema.asp 返回了 500 Internal Server Error —— 错误信息是“Microsoft VBScript runtime error ‘800a01ad’ ActiveX component can’t create object”，原因是那个 ADODB.Connection 对象，前一天被另一个 ASP 脚本 new 过一次，没 Close，也没 Set = Nothing。ASP 的对象生命周期？不存在的。它只记得自己有没有被 GC 掉。而 GC，靠运气。

　　工位双屏，左边壁纸是张北京秋天的银杏大道，右边是去年团建时在七号营地拍的雪景。两张都是我自己拍的，都没调色，灰蒙蒙的。昨天 QA 提了个 Bug：“字段描述字段为空时，前端显示 undefined”。我查了，ASP 脚本里这一行是 response.write "<desc>" & rs.fields("description") & "</desc>"。rs.fields("description") 是 Null，VBScript 把 Null 和空字符串当一回事儿处理，结果拼出来是 "<desc></desc>"。这不算错。前端解析 XML 时遇到空标签，正常。可偏偏我们前端有个正则 /<desc>(.?)<\\/desc>/g，非贪婪匹配，匹配到的是空字符串，然后塞进 React state，render 时 toString() 就是 "undefined"。谁的锅？我不知道。我只知道这个正则是前年新来的前端实习生写的，PR review 是测试顺手点的 approve，PM 没看，因为“不影响核心功能”。现在它成了元数据质量监控的盲区。我昨天把 response.write 改成 response.write "<desc>" & (rs.fields("description") & "") & "</desc>"。加了个空字符串拼接，强制类型转换。行了。但它在别的环境跑不了——测试库字段 description 类型是 ntext，生产是 varchar(max)，ntext 拼空串会报错。我说不准这个，真说不准。所以今天上午我悄悄删了那行改写，回滚到原始写法。反正 undefined 显示出来，用户点一下就知道要补描述。

　　我原以为改完 charset 就万事大吉。把 Response.Charset = "utf-8" 放在最前面，以为能防乱码。结果导出的 Excel 里中文还是问号。折腾两小时才发现是 Excel 它自己不信 HTTP header，它认 BOM。得在 Response.BinaryWrite vbByteArr 之前，手动 write 0xEF, 0xBB, 0xBF。三个字节。不多不少。我写了。可导出速度慢了四十倍。因为 ASP 的 BinaryWrite 对于大数组，性能差到反人类。三百七十二个节点的元数据树状结构，JSON 化后六万字符，转成 UTF-8 Byte 数组，ASP 要花整整十八毫秒——纯计算，不带 IO。而同一台机器，Node.js 同样逻辑，0.8 毫秒。我试过。我把那段 VBScript 拷进 Edge 控制台跑了一遍——语法报错。它根本不是 JS。我笑了一下，又关掉了控制台。现在桌面右下角时间跳到 03:47。我打算先把 Shift 键拆了，换上新的。明早再找 PM，把那个 dropdown 的 value 全改成 quote 包裹，比如 value="'sys'"，然后后端加一层白名单校验。至于 ADODB.Recordset 的字段名拼接……我先睡四小时。醒来再说。

（编辑：站长网）

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