---

一、为什么要写路径？

• 整个系统要根据功能拆分成许许多多独立的资源
• 资源之间既要完成自身的功能又要和其他资源配合
• 写路径就是为了从一个资源跳转到下一个资源

---

二、为什么写路径这事有点复杂？

1、先开发再部署

• 工程目录：我们写代码的地方，但是在服务器上运行的不是这个。
• 部署目录：经过Java源文件编译和目录重组后，IDEA就替我们准备好了可以在服务器上运行的部署目录。
• 区别：因为从工程目录到部署目录经过了目录重组，所以它们的目录结构是不同的。
• 基准：用户通过浏览器访问服务器，而服务器上运行的是部署目录，所以写路径的时候参考部署目录而不是工程目录。
• 对应关系：工程目录下的web目录对应部署目录的根目录，同时部署目录的根目录也是路径中的Web应用根目录。

2、路径的各个组成部分

从最前面一直到Web应用名称这里都是固定写法，到资源名这里要看具体是什么资源。

①具体文件
我们写代码的时候都是在工程目录下操作，所以参照工程目录来说最方便。按照工程目录的目录结构来说，从web目录开始按照实际目录结构写就好了（不包括web目录本身）。

②Servlet
访问Servlet的路径是我们在web.xml中配置的，大家可能注意到了，url-pattern里面的路径我们也是斜杠开头的，但是这个开头的斜杠代表Web应用根目录。

同样是开头的斜杠，超链接路径中的开头斜杠代表服务器根目录，Servlet地址开头的斜杠，代表Web应用根目录，怎么记呢？请看下面的准则。

---

三、准则

用通俗的大白话来解释：一个路径由谁来解析，其实就是这个路径是谁来用。

那么具体来说，哪些路径是浏览器解析的，哪些路径是服务器解析的呢？

浏览器解析的路径举例：

• 所有HTML标签中的路径
• 重定向过程中指定的路径

服务器解析的路径举例：

• 所有web.xml中配置的路径
• 请求转发过程中指定的路径

---

四、写路径的步骤

---

五、动态获取上下文路径

1、上下文路径的概念

上下文路径（context path）=/Web应用名称

2、动态获取

由于项目部署的时候，上下文路径是可以变化的，所以写死有可能发生错误。此时我们通过request对象动态获取上下文路径就不用担心这个问题了。调用下面这个方法，每一次获取的都是当前环境下实际的上下文路径的值。

request.getContextPath()

---