共计 857 个字符，预计需要花费 3 分钟才能阅读完成。
如下图所示，为了缩小 SAP 电商云 Spartacus 客户施行时不必要的配置，Spartacus 将不少页面的路由门路的默认配置，定义在如下的 default-routing-config.ts 文件里：
批改之后，产品明细页面和 homepage 的产品超链接都一齐变更了：
这个默认配置什么时候被读取，并且如何被解析的呢？
如果仅仅依照 product 作为关键字搜寻，那么匹配后果太多了，因为这个单词太 generic 了：
而且 RoutesConfig 这个类型，多半都是被代码动静解析的。
换个思路，把 product 改成 product2，看看会不会报错：
这回难堪了，鼠标放上去，显示的 url 指向 home 链接，阐明 product 明细页面的 url 基本就没有生成，这条路也行不通。
再依据 paramsMapping 搜寻，因为咱们的代码，必定在某处，会解析这个字段：
果然，就在 semantic-path.service.ts 里：
在 semantic-path.service.ts 里增加如下打印语句：
咱们看下第一行输入，这个 / 和 login 是怎么被解析的。
在 Login.componment.html 里有个 pipe：
遇到上面这行代码：
<ng-template #login>
<a role="link" [routerLink]="{cxRoute:'login'} | cxUrl">{{'miniLogin.signInRegister' | cxTranslate}}</a>
</ng-template>就会读取 Spartacus 里的配置，把基于语义的路由配置，转换成 url.
从 routingConfigService 里读取配置：
login 页面 url 搞清楚了，那么 product 页面呢？
奇怪，如果间接拜访如下 url：
http://localhost:4200/powerto…
页面关上后，没有看到和 product 相干的执行逻辑：
那么 Spartacus 怎么晓得要加载 product 明细页面呢？
咱们后续的文章会分享。
更多 Jerry 的原创文章，尽在：” 汪子熙 ”: