内容摘要：ASP系统在1996年随着IIS 3.0一起出现时，开发者往HTML里嵌入``就能跑起逻辑。那会儿PHP还在襁褓里，JSP没影。微软给Windows服务器塞了个解释器，请求进来逐行读脚本，遇到HTML

ASP系统在1996年随着IIS 3.0一起出现时，开发者往HTML里嵌入`<% %>`就能跑起逻辑。那会儿PHP还在襁褓里，JSP没影。微软给Windows服务器塞了个解释器，请求进来逐行读脚本，遇到HTML就吐出去，遇到VBScript就执行。简单粗暴，但管用。

我见过一个跑了十几年的老系统，代码里混着VBScript、JScript和一堆`On Error Resume Next`。数据库连接字符串硬编码在`global.asa`里，密码是明文。维护它的老工程师说，2003年那会儿一天能改三回需求，ASP改起来快，复制粘贴就能上线。这种“快”是有代价的——页面逻辑和数据库查询搅在一起，改一个字段要在十几个`.asp`文件里搜替换。

ASP的核心是`Request`和`Response`对象。`Request.Form`拿POST数据，`Request.QueryString`拿URL参数，`Response.Write`往客户端写东西。没有路由，没有中间件，没有依赖注入。一个`default.asp`就是入口，后面全靠``拼起来。这种模式在小型项目里反而高效，因为所有东西都在眼皮底下，不需要翻框架文档。

但问题很快暴露。用户输入直接拼进SQL语句，`' OR '1'='1`就能绕过登录。2000年前后，大量ASP站点被注入攻击，有些页面被挂上木马，有些整个数据库被导走。微软后来推`Server.HtmlEncode`和参数化查询，可老代码改不动，新项目又嫌ASP太土。2002年ASP.NET出来，微软自己把ASP归为“经典ASP”，意思很明确：别用了，换吧。

不过ASP没死透。我去年还帮人排查过一个内网系统，Windows Server 2003，IIS 6.0，跑着ASP。原因是业务逻辑太特殊，重写成本高，而且内网不对外，安全风险可控。管理员给IIS打了所有补丁，把`.asp`映射限制在特定目录，勉强维持着。这种场景不少见——银行、医院、工厂的老系统里，ASP像一块化石，嵌在技术栈底层，动它就要动整条业务链。

从技术角度看，ASP的失败在于它把“简单”和“混乱”划了等号。没有强制分层，没有类型检查，没有编译期错误提示。一个变量拼错，运行时才报错，而且错误信息直接吐给用户，暴露物理路径。但它的成功也在于简单——学习曲线几乎为零，会HTML就能写ASP。这种低门槛让它在中小项目里迅速铺开，也让它在大项目里迅速失控。

现在回头看，ASP更像一个过渡产物。它证明了服务器端脚本能跑通，但没解决工程化问题。PHP后来靠Composer和框架补上了，ASP.NET用编译和强类型重写了规则。经典ASP留下的，除了那些还在跑的老系统，就是一套“快速但脆弱”的开发记忆。用的人少了，可偶尔翻到十年前的代码，看到`Response.Write "
"`，还是能想起那个HTML和逻辑混在一起、改一行刷新一次页面的年代。