用ASP判断文件是断文否存在，最直接的断文办法就是调用FileSystemObject。这东西从IIS 5时代就跟着ASP混，断文到现在依然能打。断文我见过不少项目用Server.MapPath拼个路径，断文然后拿FSO去查，断文代码写起来就三行：

Set fso = Server.CreateObject("Scripting.FileSystemObject") If fso.FileExists(Server.MapPath("/data/config.xml")) Then Response.Write "文件在" End If Set fso = Nothing

但这里有个坑，断文很多人不释放对象。断文ASP的断文COM对象不显式销毁，IIS进程池里的断文内存会慢慢涨。我习惯在If块结束后立刻Set fso = Nothing，断文哪怕后面还有别的断文逻辑，先释放再说。断文

FileExists方法接收的断文是物理路径，不是断文URL。有人直接传“/images/logo.png”，结果永远返回False。Server.MapPath把虚拟路径转成物理路径，这一步不能省。如果站点部署在虚拟目录里，MapPath还能自动处理根路径的映射，比手动拼字符串靠谱。

另一个容易忽略的点是权限。IIS的匿名用户账户（IUSR）得有目标目录的读取权限，否则FileExists也会返回False，哪怕文件确实存在。我调试过一个上传功能，文件明明写进去了，判断就是不过。查了半天，发现是上传目录的NTFS权限没给IUSR读取。后来改成用FileSystemObject的FileExists之前，先确认目录权限，或者干脆用ADSI查，但ADSI更重，没必要。

还有一种情况：文件在网络共享路径上。FileExists支持UNC路径，比如“\\server\share\file.txt”。但ASP进程得用有网络访问权限的账户跑，默认的IUSR不行。得改应用程序池标识，或者配置委派。这种场景不多，碰上了就是坑。

有人问能不能不用FSO。可以，用Server.CreateObject("ADODB.Stream")去尝试打开文件，能打开就存在，报错就不存在。但Stream对象开销比FSO大，而且错误处理麻烦，不推荐。还有用XMLHTTP发HEAD请求判断URL的，那是判断HTTP资源，不是本地文件，两码事。

性能方面，FileExists本身很快，就是一次系统调用。但如果放在循环里反复调用，比如遍历目录下几百个文件逐个判断，那就该换思路了。直接用Folder.Files集合遍历，或者用FileSystemObject的GetFolder方法拿目录对象，效率高得多。

最后说个实际案例。有个老系统用ASP做后台，配置文件放在“/config/site.ini”。某次运维把文件挪到了“/config/site.ini.bak”，但代码里判断逻辑写的是：

If fso.FileExists(Server.MapPath("/config/site.ini")) Then ' 加载配置 Else ' 用默认值 End If

结果文件改名后，系统静默切换到默认配置，没人发现。后来加了个日志，判断失败时写一条记录，才暴露出来。所以判断文件存在只是第一步，不存在时的分支逻辑得想清楚，别让静默失败坑了。

写ASP的人越来越少，但维护老系统时这些细节绕不开。FSO的FileExists够用，注意路径、权限、对象释放，基本不会出岔子。

(责任编辑：焦点)