context-path 概念早期可能是出现在 servelt 容器。比如 tomcat 在部署应用（或模块）时，每个应用（或模块）会配置一个 context-path，起到隔离和避免路径冲突的效果。

对 solon 而言，相当于一个 webapp 的“路径前缀”（且与友商的配置略有不同）。


### 1、所谓路径前缀

比如果有应用地址（未配置 context-path 时）：`http://xxx/test/get`。

当配置了context-path `/demo/` 后就需要用 `http://xxx/demo/test/get` 发起请求（在域名之后，多了段前缀）。

### 2、关于 context-path 的两种配置（基于 pathNew 的变化实现）


| 配置                                                 |  差别         | 差别说明                                              |
| ------------------------------ | -------- | ---------------------------- |
| `server.contextPath: "/test-service/"`    |                | 原路径仍能访问（v1.11.2 后支持）     |
| `server.contextPath: "!/test-service/"`   | `!` 开头     | 强制，原路径不可访问（v2.6.3 后支持）     |

当有 `context-path` 配置时


| 接口                     | 说明 | 
| -------------- | -------- | 
| `ctx.path()`           | 是原始请求路径     | 
| `ctx.pathNew()`     | 是去掉 `context-path` 后的请求路径    | 


### 3、两种配置效果示例说明

比如有原始地址：`http://xxx/test`，使用不同配置的效果：

| 请求地址                                |  无配置             | `"/test-service/"` |  `"!/test-service/"` |
| ------------------------ | ------------ | -------- | -------- | 
| `http://xxx/test` （原路径）      |   可访问            | 可访问     |  404 错误   | 
| `http://xxx/test-service/test`    |  404 错误         | 可访问     |   可访问  | 


提醒：一般情况使用，添加 `!` （表示强制）才是大多数人的预期效果。

### 4、为什么要有两种配置？

在集群环境（比如微服务）做内部的 http rpc （或者 http call）请求时。如果 server 加了 context-path（或者变更），client 就必须要修改请求路径。没办法作到一套代码到处可用。

所以有了 “原路径仍能访问” 的配置策略。可以实现外部如何变化，内部请求都可不变！

### 5、为什么默认不是“强制”的策略？

在生产部署时，当遇见有 context-path 需求的场景。一般会有 nginx 或 tomcat 等，本身就有 path 前缀配置，相当于已经起到了过滤的效果，应用只需要支持有前缀的需求。

所以默认不采用“强制”方式，可以同时兼容两种应用需求。（但有些场景下，确实需要强制）