Pinia仅负责未读消息总数的集中存储与响应式管理，轮询、多端同步及界面更新需结合外部机制实现：一、用action封装带防抖/节流的定时拉取逻辑；二、通过localStorage+storage事件或BroadcastChannel实现多标签页同步；三、服务端支持时优先使用WebSocket替代轮询；四、利用localStorage持久化缓存防止刷新丢失。
Pinia 本身不处理轮询，也不自动同步未读消息总数——它只负责**集中存储和响应式管理**这个状态。真正实现“轮询获取 + 多端同步 + 界面更新”的，是把 Pinia 作为状态中枢，再配合外部机制来完成。
一、用 action 封装轮询逻辑，避免重复请求
在 store 中定义一个带防抖/节流或标记位的轮询 action，确保同一时间最多一个请求在进行：
- 用 ref 记录是否正在轮询中（isPolling），避免多个组件触发多次并发请求
- 使用 setTimeout 或 setInterval 实现定时拉取，推荐用 setTimeout 递归方式，更易控制启停
- 请求成功后调用 this.unreadCount = res.data.unread 直接更新 state，触发所有依赖该值的组件重绘
- 失败时建议保留旧值，并可加 retry 机制（比如指数退避）
二、多标签页间未读数实时同步，靠浏览器通信机制
单页应用刷新后状态会丢失，多标签页各自轮询会导致数据不一致（比如 A 标签页已读一条，B 标签页仍显示+1）。解决方法不是让 Pinia “自己同步”，而是借助浏览器能力通知其他实例：
- localStorage + storage 事件：当本页更新 unreadCount 后，写入 localStorage；监听 storage 事件，收到变更就同步到当前 store.state
- BroadcastChannel API：更现代、专为跨标签通信设计，发送方调用 channel.postMessage({ type: 'UNREAD_UPDATE', value: 5 })，所有监听 channel 的 store 实例收到后更新本地 state
- 不推荐直接用 postMessage + iframe 或自建 WebSocket 做纯前端同步——除非你已在用 WebSocket 与服务端通信，此时可复用连接广播
三、服务端有推送能力时，优先用 WebSocket 替代轮询
轮询本质是“被动查”，而未读消息属于典型的“有变更才需通知”场景。如果后端支持，应升级为实时通道：
- 在 store 的 onMounted（或 useStore 初始化时）建立 WebSocket 连接，并监听 unread_update 类型消息
- 收到消息后直接更新 this.unreadCount，Pinia 自动触发视图更新
- 断连时自动重连，并在重连成功后补拉一次最新未读数（防止期间丢失）
- 注意：WebSocket 消息体里应包含完整未读数（而非 delta），避免本地计算出错
四、持久化未读数，防止页面刷新丢失感知
用户刚看到“3 条未读”，刷新页面变成 0，体验极差。虽然未读数本质是服务端状态，但前端可缓存一个“可信快照”：
- 每次成功更新 unreadCount 后，用 useLocalStorage('unread_cache', ...) 存一份带时间戳的缓存
- 页面加载时，先从 localStorage 读取缓存并赋值给 state，再发起首次轮询或 WebSocket 连接
- 若服务端返回值不同，以服务端为准覆盖；若网络失败，至少保留最近一次有效值供展示
