Spartacus获取CMS组件时GET请求过大问题的解决方案问询

共性问题背景：Spartacus默认将多个CMS组件的查询合并为单次GET请求，该设计在大多数场景下能有效减少请求数，但在引入大型分类树等需要一次性获取数百个CMS组件的场景下，会导致GET请求URI长度超过服务器限制。

以下是已验证可落地的解决方案，可根据自身业务场景选型：

• 方案1：调整CMS组件请求的批量合并阈值
  实现方式：通过配置重写Spartacus默认的CmsConfig中componentsLoading.batchSize参数，将默认的单次请求合并组件数量从默认值（通常为100）下调到合适阈值（建议设置为30~50，可根据实际组件ID长度调整），框架会自动将超过阈值的组件查询拆分为多个并行GET请求，每个请求的URI长度都在安全范围内。
  适用场景：不想修改后端逻辑、不想调整现有业务代码，需要同时兼容客户端渲染和SSR场景。
  优势：改动量极小，无业务逻辑侵入，完美兼容原有Spartacus生命周期。
  注意事项：提前确认后端对同接口并行请求的限流规则，避免拆分后触发访问限制。

• 方案2：SSR阶段单独裁剪组件请求范围
  实现方式：自定义CmsItemsLoadStrategy，在SSR渲染上下文下过滤掉非首屏必须的CMS组件ID，仅请求首屏可见的组件，剩余组件等到客户端Hydrate完成后再异步加载。
  适用场景：已经在客户端实现了组件懒加载，仅SSR阶段存在请求超长问题的场景。
  优势：不影响原有客户端交互逻辑，还能提升SSR渲染速度，降低服务端资源消耗。
  注意事项：需要准确识别首屏必须组件，避免SSR输出内容缺失导致的Hydrate不匹配报错。

• 方案3：基于后端分页的渐进式组件加载
  实现方式：自定义CMS组件加载器，在组件ID列表超过设定阈值时，自动按后端分页参数分批发起请求，第一批优先请求首屏所需组件，后续批次在浏览器空闲时间异步加载，整个分批逻辑封装在加载层，上层CMS组件的获取逻辑完全不需要修改。
  适用场景：后端已经支持CMS组件接口分页能力的场景。
  优势：完全兼容原有业务代码，请求大小完全可控，额外带来首屏加载速度提升。
  注意事项：需要处理好分批请求的组件缓存逻辑，避免重复发起请求。

• 方案4：静态化高频大型组件数据
  实现方式：如果分类树等大型导航结构更新频率较低，可以通过构建时拉取、静态资源托管的方式直接将菜单JSON打包到前端产物中，或者单独存放在静态CDN，前端初始化时直接读取，不需要走CMS组件批量查询接口。
  适用场景：大型导航结构更新频率低，允许分钟级到小时级更新延迟的场景。
  优势：完全规避了CMS组件请求超长问题，还能大幅提升导航模块的加载速度。
  注意事项：需要配套对应的热更机制，避免前端静态数据和后端配置不同步。

选型参考 #

• 追求最小改动优先选择调整批量合并阈值方案
• 仅SSR阶段存在问题优先选择SSR阶段裁剪请求范围方案
• 导航结构更新频率低优先选择静态化高频数据方案

内容的提问来源于stack exchange，提问作者Mirosław Grochowski