核心是连接管理、消息分发、弹窗去重、页面卸载清理四点；WebSocket 应封装为单例模块，用 provide/inject 或 Pinia 管理；消息需 ID 去重+定时清理；弹窗通过 Teleport + 响应式队列驱动；路由切换时暂停消费而非断连。
Vue 项目里用 WebSocket 做全局弹窗通知，核心不是“怎么连上 WebSocket”，而是“怎么让所有组件都能安全、及时、不重复地收到消息并触发弹窗”——连接管理、消息分发、弹窗去重、页面卸载时的清理，这四点没处理好，上线后要么收不到通知，要么弹窗叠成山。
WebSocket 实例该挂在哪？别挂在某个组件里
挂 data 或 setup() 里会导致组件销毁后连接丢失，或多个组件重复 new WebSocket；挂 globalProperties 又难统一控制生命周期。最稳妥的是封装成独立模块，配合 provide/inject 或 Pinia 管理单例状态。
- 用
const ws = new WebSocket('wss://...')创建后，立刻用ws.onopen和ws.onerror做连接确认与降级兜底（比如 fallback 到轮询） - 在
onmessage回调里不做具体业务渲染，只做标准化消息分发：解析event.data→ 校验type字段 → 用emits（组合式 API）或$emit（选项式）广播给监听者 - 必须手动监听
beforeunload或onbeforeunload，调用ws.close()，否则浏览器标签页关掉后连接还挂着，服务端可能持续发包
弹窗组件如何避免重复触发？靠消息 ID + 时间窗口去重
后端推送的通知可能因网络重传、心跳补发等原因重复到达，前端不做去重，用户会看到同一消息弹出 2–3 次。不能只依赖后端保证“恰好一次”，客户端必须有防御逻辑。
- 每条通知消息必须带唯一
id字段（推荐后端生成 UUID 或时间戳+序列号），前端存进 Set：const shownIds = new Set() - 收到消息后先检查
if (shownIds.has(msg.id)) return，再调用弹窗函数，然后shownIds.add(msg.id) - Set 不清空会内存泄漏，加个定时器：每 5 分钟执行
shownIds.clear()，或只保留最近 100 条 ID（用Array+shift()维护队列） - 不要用
localStorage做去重——多标签页场景下不同页面无法共享 Set，但 localStorage 是共享的，反而导致本该弹的没弹
全局弹窗怎么从任意组件触发？用 Teleport + 事件总线解耦
不能让每个业务组件都 import 弹窗组件再 v-if 控制显示，那样会污染逻辑且难以统一配置（比如关闭按钮位置、超时时间）。应该把弹窗 DOM 抽离到 <Teleport to="body">，由一个根级 watcher 驱动。
分析 Vue 3 Composition API 使用情况——审计响应式模式、可组合函数设计、ref 与 reactive 的选择、计算属性、watcher 使用及组件……
立即学习“前端免费学习笔记（深入）”；
- 定义一个响应式通知队列：
const notifications = ref([])，用unshift()插入新通知（保证最新在前） - 弹窗组件监听
notifications，每个通知对象包含id、title、content、timeout（毫秒）等字段 - 点击关闭或超时自动移除时，用
notifications.value = notifications.value.filter(n => n.id !== id)，避免直接splice引起响应式失效 - 如果用 Pinia，把
notifications放进 store，所有组件通过useNotificationStore().add({ ... })触发，彻底解耦
Vue Router 切换时 WebSocket 还在吗？连接状态必须显式维护
WebSocket 是长连接，和路由无关，但用户切到其他页面（比如设置页）时，你可能不想再收通知弹窗——这不是断开连接，而是“暂停消费”。硬关连接再重连会丢消息，应该用开关控制分发逻辑。
- 在路由守卫中记录当前页面是否“允许弹窗”：
router.beforeEach((to) => { isNotificationEnabled.value = !to.meta.silentNotify }) -
onmessage中加判断：if (!isNotificationEnabled.value) return，但依然要解析、校验、存入本地缓存（如pendingNotifications.push(msg)） - 回到首页时，把缓存里的未处理消息重新触发分发，避免“人回来了，消息却丢了”
- 注意：Vue Router 的
scrollBehavior或keep-alive缓存组件不会影响 WebSocket 实例，但可能让旧组件的onmessage监听器还在运行，造成重复消费——务必在onUnmounted中移除事件监听或设 flag 屏蔽
真正难的不是写通 WebSocket，而是让弹窗既不漏、也不重、还不卡——消息队列长度、重连退避策略、连接健康检查（比如发 ping/ping 超时自动重连）、以及多端登录时的踢出通知，这些边界情况往往在线上才暴露。先跑通基础链路，再按实际压测数据补漏，比一上来堆“完美设计”更靠谱。
