前端中"一份数据两份消费"最经典的场景就是同一个接口的数据，被两个或以上不同组件同时使用。
这在实际开发中非常常见，比如：
场景一：列表页 + 详情页/编辑弹窗
用户点击列表中的某一行，弹出一个编辑弹窗。列表数据和弹窗数据来自同一个接口（比如 GET /api/users/123）。
- 消费方 1：列表组件，展示用户姓名、头像等摘要信息。
- 消费方 2：编辑弹窗组件，展示该用户的全部字段（邮箱、电话、地址等）。
问题：如果不做处理，弹窗打开时会再调一次接口，造成重复请求。
场景二：Tab 切换 + 面包屑/导航栏
页面顶部有 Tab 标签页（如"概览"、"详情"、"设置"），每个 Tab 的内容区需要数据。同时，页面顶部的面包屑导航或侧边栏菜单也需要根据当前 Tab 的数据来高亮或显示标题。
- 消费方 1：Tab 内容区，渲染具体数据。
- 消费方 2：面包屑/导航栏，显示当前 Tab 的名称和路径。
问题：如果每个组件各自去请求，不仅浪费网络，还可能导致面包屑和内容区显示不一致。
场景三：购物车 + 底部结算栏
电商页面的购物车列表和底部的"总计/结算"栏，数据都来自购物车接口。
- 消费方 1：购物车列表，展示每个商品的数量、单价、小计。
- 消费方 2：底部结算栏，展示总价、优惠金额、预估运费。
问题：如果两个组件各自维护一份数据副本，用户修改数量后，结算栏可能不会同步更新。
场景四：实时仪表盘 + 历史趋势图
监控系统中，一个 WebSocket 推送的实时数据流，同时被两个图表组件消费。
- 消费方 1：实时数值仪表盘，显示当前 CPU、内存使用率。
- 消费方 2：历史趋势折线图，将数据点追加到时间序列中。
问题：如果每个组件各自订阅 WebSocket，会造成连接浪费和数据不一致。
核心痛点
这类场景的共性问题是：
- 重复请求：同一个接口被多次调用，浪费带宽和服务器资源。
- 数据不一致：两个组件各自维护一份数据副本，一个改了另一个不知道。
- 状态不同步：用户在一个组件中操作后，另一个组件无法自动感知。
最佳实践方案
针对这类场景，前端常用的优化手段是：
请求上移 + Props 透传（最简单，适合简单场景）
将接口请求放在父组件或页面容器中，通过 props 把数据传给子组件。
缺点：组件层级深时，需要层层透传，比较麻烦。
全局状态管理（最推荐，适合中大型项目）
用 Pinia（Vue）或 Zustand/Redux（React）统一管理数据。
组件只从 Store 中读取数据，数据变更时所有消费方自动更新。
请求缓存库（适合数据密集型场景）
使用 React Query / SWR / Vue Query 等库。
这些库自带请求去重功能：同一时间、同一参数的请求，只会发一次，所有组件共享同一个 Promise 和缓存结果。
WebSocket 单连接 + 广播（适合实时数据场景）
只建立一个 WebSocket 连接，收到数据后写入 Store，再由 Store 分发给所有消费方组件。
一句话总结：一份数据两份消费，核心不是"怎么请求"，而是"怎么共享"。用状态管理或请求缓存把数据收拢到一个地方，所有组件都去那里读，自然就解决了重复请求和状态不一致的问题。