共计 1170 个字符，预计需要花费 3 分钟才能阅读完成。
Spartacus 开源我的项目提供将 Angular 实现的 电商 Storefront 站点作为 PWA 运行的性能。
这进步了用户性能，改善了用户体验，增加了另一个缓存层并缩小了服务器端渲染 (SSR) 服务的负载。
PWA 的工作形式是，对于利用程序定义的文件列表，它会依据文件的内容生成文件哈希。客户端浏览器依据这个 hash 值来判断文件是否产生了更改。如果产生更改，则浏览器须要从新加载。
每次重新部署(new deployment) 会导致文件的 hash 发生变化。
在构建 Spartacus 并将其部署到 CCV2 Cloud 时，会产生以下步骤：
- 构建应用程序：为必要的文件（包含 index.html）生成哈希
- 将
index.html中的占位符OCC_BACKEND_BASE_URL_VALUE替换为以后环境的理论 OCC API url - 启动 Storefront Service
因为 index.html 在 CCV2 生成哈希值 后才失去调整，PWA 因为哈希不匹配而无奈失常工作，这被视为潜在的平安问题。
从缓存资源列表中删除 index.html 的办法并不能看成一个欠缺的解决方案。
因为那样的话，每次 full page 从新加载都会进入 SSR，这样的话应用 PWA 意义就不大了。
如果部署 Spartacus 到 CCV2，之后拜访 Storefront 遇到 502 bad gateway 谬误的话：
ct() failed (111: Connection refused) while connecting to upstream, client: 10.244.2.13, server: ~^.spartacus-app.$, request: “GET /app-fr/fr/EUR/ HTTP/1.1”, upstream: “http://127.0.0.1:4200/app-fr/fr/EUR/”, host: “something.model-t.cc.commerce.ondemand.com”
一个可能的谬误就是，在 Spartacus 代码里：遗记将代码里的 occ baseUrl 的配置正文了：
backend: {
occ: {baseUrl: 'https://localhost:9002', ---> you can comment it out by applying //}
},这是因为 OCC_BACKEND_BASE_URL_VALUE 在幕后被 CCv2 主动 替换，CCv2 将其替换为客户要部署到的环境的 api，因而，无需在 Spartacus 中设置动态 occ baseUrl – 后者仅仅是在本地开发时才须要设置。
换言之，app.module.ts 中 provideConfig() 的 backend.occ.baseUrl 的值优先于 meta 标签的值，所以如果心愿 base URL 由 meta 标签动静驱动，不要定义 provideConfig() 中的 baseUrl.
