很多人对它们都不陌生，在众多的WEB程序中，使用Server.MapPath和Request.PhysicalApplicationPath来操作目录/文件的几率参半，我曾经也经常混用，然而时间久了。发现Request.PhysicalApplicationPath有点“麻烦”？
其实在一般的应用程序中，感觉不到两者的区别，而在一些存在“虚拟目录”、存在多级子目录、需要虚拟目录相互文件操作的站点中，就可以知道它们的区别了。我的总结如下：
1、相对当前路径的文件操作：
可以使用Server.MapPath("test.txt")、Server.MapPath("a/test.txt")、Server.MapPath("../b/test.txt")，这个时候使用Request.PhysicalApplicationPath就很难定位到文件；
2、绝对路径的文件操作：
这个时候两者都可以，有点注意的是Server.MapPath中的绝对是“面向”站点而言的，不会因为“虚拟目录”本身的属性不同而变化，Request.PhysicalApplicationPath就并非如此。
打个比方：主站点指向D:/wwwroot/，虚拟目录指向E:/wwwroot/a/，取名为a。
那么如果我要操作虚拟目录下的E:/wwwroot/a/test.txt，可以使用Server.MapPath("/a/test.txt")，又或者直接使用Server.MapPath("~/test.txt")；
那么用Request.PhysicalApplicationPath该怎么写？
很多人数是：Request.PhysicalApplicationPath + "test.txt"，我说不一定，为什么？
因为要是该虚拟目录有单独的应用池，Request.PhysicalApplicationPath就是E:/wwwroot/a/，后面加上test.txt就是E:/wwwroot/a/test.txt；
但要是该虚拟目录没有单独的应用池，Request.PhysicalApplicationPath就是D:/wwwroot/，不管你后面怎么加，都定位不到我要找到文件了。呵呵……
3、跨虚拟目录的文件操作：
比如我现在要操作虚拟目录b下的test2.txt文件，使用Server.MapPath("/b/test2.txt")就没有问题（前提是我有操作权限，没有权限是另外一回事）。
而Request.PhysicalApplicationPath根本就无法找到其他的虚拟目录下的文件，不信谁试试，再告诉我方法？！！！
综上所述，我个人以后更倾向使用Server.MapPath。