Props 无法单独实现全局通知弹窗，因为它只支持父子组件之间的单向数据传递；而全局消息弹窗通常与业务组件不存在直接父子关系。因此，要实现全局通知消息队列的统一渲染，通常需要结合 Pinia 状态管理，或使用 provide/inject + 事件总线来完成发布-订阅模式。

从 Vue 组件通信的角度来看，Props 这种机制并不适合“在全局弹窗中渲染通知消息队列”这类跨层级、且有多个消息来源的场景。原因很简单：Props 只能处理父组件到子组件的单向传值。但全局通知系统要解决的是“任意组件都可以发送通知消息”，再由全局弹窗组件（通常挂载在 App 根节点或通过 Portal/Teleport 渲染）统一接收并展示整个消息队列。仅依赖 Props 显然无法满足这类需求，必须配合其他组件通信方案。

为什么不能只靠 Props

全局通知弹窗一般是独立挂载的，例如放在 的最外层，或者通过 Teleport 直接渲染到 body 底部。它与业务组件——比如按钮、表单、列表等——通常并没有直接的父子关系：既不是它们的父组件，也不是它们的子组件。问题就在这里，Props 只适用于明确的父子传参链路；一旦涉及兄弟组件通信、跨路由通信，甚至跨异步组件传递消息，这种方式基本就无法胜任。

正确做法：Props 配合事件总线或状态管理

实现全局通知弹窗的核心思路是“发布-订阅”模式。你需要一个集中式的消息通道，让任意组件都能调用 notify({ type: 'success', content: '提交成功' })，而通知弹窗组件负责监听这个通道，并维护自己的通知队列进行渲染。

• 推荐使用 Pinia（Vue 3 官方更推荐的状态管理方案）：可以创建一个 useNotificationStore，其中包含 queue 数组和 add(item) 方法；全局弹窗组件 通过 store.queue 响应式渲染；任意业务组件只需引入 store 并执行 store.add({...}) 即可发送通知消息
• 轻量替代方案：使用 provide/inject + 事件总线：可在 main.js 或 App.vue 中通过 provide('notify', (msg) => {...}) 提供通知方法，再结合简单的事件总线（如 const bus = mitt()），由弹窗组件在 onMounted(() => bus.on('notify', handler)) 中监听消息，业务组件则通过 bus.emit('notify', msg) 触发通知
• 不推荐：通过 Props 一层层透传消息：例如从 Button → Page → Layout → App → Notification 逐层传递，不但代码冗长、维护成本高，还会破坏组件封装性，同时也很难优雅支持动态新增/删除通知、自动关闭、手动清除等常见交互需求

弹窗组件如何渲染队列（关键细节）

如果你采用的是 Pinia，全局通知弹窗组件通常可以这样实现：

• 使用 v-for 遍历 store.queue，并为每个通知项生成唯一 id（建议使用 Date.now() + Math.random()）
• 给每条通知绑定 :key="item.id"，确保 Vue 在列表渲染时能够正确复用 DOM
• 若需要自动关闭通知，可通过 setTimeout 设置定时器，并在 onBeforeUnmount 中及时清理，避免出现内存泄漏问题
• 当关闭某一条通知时，应调用 store.remove(item.id)，而不是直接 splice 操作原数组，以保证状态更新更清晰且符合响应式管理思路

如果非要“带 Props 的弹窗”怎么用

只有当弹窗本身是某个页面中的局部子组件（例如仅在订单页中使用的提示框）时，才适合通过 Props 控制显示状态和内容：

• 父组件传入 :visible.sync="showTip" 和 :message="tipMsg"
• 弹窗内部不维护消息队列，只负责渲染单条通知；如果要展示下一条消息，需要由父组件先更新 tipMsg，再设置 showTip = true
• 这种方式本质上属于“受控组件”模式，适合结构简单的提示场景，但并不能满足“多个通知消息排队展示”的全局弹窗需求