React/Node/Mongoose栈预订模态组件请求加载耗时过长优化咨询

核心思路 #

保留用户个性化默认地点特性的同时无冗余存储，让地点列表请求和默认地点的时间表请求并行执行，直接砍掉900ms的串行等待耗时。

具体实现方案 #

方案一：仅存储默认地点ID（无冗余、改造成本最低） #

你提到的方案1的冗余问题完全可以避免，不需要在Redux里存完整地点对象，仅存默认地点ID即可：

• 用户表仅存储默认地点的ID作为外键，完全没有数据冗余，是常规的数据库设计方案
• 用户登录时同步把用户的默认地点ID拉取到Redux中，不需要等地点列表接口返回
• 组件初始化时直接从Redux拿到默认地点ID，立刻发起时间表拉取请求，和地点列表拉取请求并行执行
• 等地点列表返回后，再把选中态和地点列表做匹配即可，不影响时间表的加载进度

方案二：调整地点列表接口返回结构（不需要额外存储） #

如果不想在登录逻辑里加额外的默认ID同步逻辑，可以让后端调整地点列表接口的返回结构，新增defaultLocationId字段：

{
  "defaultLocationId": "xxx", // 当前用户的默认地点ID
  "locations": [/* 全量地点列表 */]
}

• 接口响应后优先提取defaultLocationId，立刻发起时间表请求，不需要等全量地点列表的状态更新完成，相当于把原来两次串行请求的等待间隔压缩到毫秒级
• 不用修改任何用户侧的存储逻辑，也保留了个性化默认地点特性

额外可叠加的优化项 #

• 把7天时间表的7个独立请求合并为1个批量接口，直接解决浏览器请求队列阻塞导致的额外900ms延迟，时间表拉取耗时直接从1800ms降到900ms
• 对常用地点的时间表做本地缓存（比如localStorage），设置1~2小时的有效期，用户二次访问时直接用缓存渲染，后台静默更新数据，感知速度接近秒开
• 首屏加载阶段展示时间表骨架屏，降低用户的等待感知

内容的提问来源于stack exchange，提问作者Aaron Ahn