ASP脚本代码是在哪里执行的

你写下一行 <% Response.Write("Hello") %>，按下保存，码里然后在浏览器里输入网址。执行屏幕上跳出“Hello”。本代这个“Hello”不是码里浏览器自己变出来的——它从服务器那边跑了一圈才到你眼前。关键问题来了：那段<% %>里的执行代码，到底在哪儿跑的本代？

答案是：在Web服务器上执行的，具体来说，码里是执行在服务器端的ASP引擎里。 浏览器从头到尾就没见过你写的本代那行脚本。它拿到的码里只是执行后的纯HTML结果。

我拿IIS（Internet Information Services）举个例子。执行假设你有个文件叫test.asp，本代里面混着HTML和ASP脚本。码里当浏览器请求这个文件时，执行IIS不会直接把文件内容扔回去。它先看扩展名——.asp，好，这不是静态的.html。于是IIS把请求转交给一个叫asp.dll的ISAPI扩展。这个DLL就是ASP引擎的核心。它把文件从头到尾读一遍，遇到普通HTML就原样保留，遇到<% %>包裹的代码就当场执行。

执行发生在服务器的内存里。比如你写<% For i = 1 To 3 %>，引擎就在服务器上跑这个循环，循环三次，每次把循环体里的HTML片段拼接到输出缓冲区。整个过程你可以在服务器任务管理器里看到w3wp.exe（IIS工作进程）的CPU占用微微跳动——那就是你的脚本在烧CPU。

有个细节容易搞混：ASP用的是VBScript或JScript，这些语言本身没有“编译成机器码”那一步。引擎是解释执行的，读一行、解析一行、跑一行。所以如果你在<% %>里写了个死循环，服务器那个工作进程就卡死了，浏览器一直转圈，直到超时。我早年就干过这事——写了个Do While True忘了加退出条件，结果整个测试服务器上的其他站点也跟着遭殃。这就是服务器端执行的直接证据：你搞崩的是服务器，不是自己的浏览器。

再往底层看一点。ASP引擎执行脚本时，它其实是在一个叫脚本引擎宿主的环境里跑。IIS把asp.dll加载到工作进程，asp.dll又去调用vbscript.dll或jscript.dll。这些脚本引擎提供对象模型——Request、Response、Server、Session、Application。你在代码里写Request.Form("name")，这个Request对象是服务器在内存里构造好的，跟浏览器没半毛钱关系。浏览器只是把表单数据POST过来，服务器解析HTTP请求体，填充Request.Form集合，然后你的脚本才能读到。

那浏览器到底干了什么？它只干了一件事：发送HTTP请求，然后等待。服务器执行完所有ASP代码后，把纯HTML（可能还有CSS、JS）通过HTTP响应写回去。浏览器收到的是类似这样的东西：

<html><body>Hello</body></html>

你右键查看网页源代码，永远看不到<% %>。因为那些代码在服务器上已经“蒸发”了，变成动态生成的HTML文本。这个机制和PHP、JSP、ASP.NET是一回事——服务器端脚本语言的共同特征。

有人可能会问：那我能不能在浏览器里执行ASP代码？不行。浏览器只认识HTML、CSS、JavaScript。ASP是微软在90年代搞出来的服务器端技术，它依赖Windows和IIS。你就算把.asp文件直接拖进Chrome，Chrome也只会把它当纯文本显示，或者干脆下载下来。因为Chrome的渲染引擎里根本没有VBScript解释器，更没有Response对象。

我见过一个经典错误：有人在<% %>里写MsgBox "hi"，然后抱怨浏览器没弹窗。这行代码在服务器上执行时，MsgBox是VBScript的弹窗函数——但服务器是后台服务，没有桌面交互，所以它要么静默失败，要么弹在服务器控制台上（如果允许交互的话）。浏览器那边啥也看不到。这就是没搞清楚执行位置的典型翻车。

所以下次你写ASP的时候，脑子里要有一张图：你的代码跑在远端那台嗡嗡响的机房里，跑在w3wp.exe的某个线程上。浏览器只是个大喇叭，把服务器算完的结果喊给用户听。脚本执行的位置，决定了你能用什么对象、能访问什么资源、以及为什么你的Response.Write能变成屏幕上的字。