Emit 异步通知如何在子组件完成异步操作后通过 emit 通知父组件结束 Loading

子组件应在异步流程真正收尾（含数据处理、错误判断、UI准备就绪）后 emit('loading-change', false)，父组件通过 Map 聚合多来源 loading 状态并用 computed 统一控制遮罩层等；成功 emit('ready')，失败 emit('error')，避免仅在 then 中关闭 loading 导致状态卡住。

子组件完成异步操作后，通过 emit 通知父组件结束 loading，关键在于“时机准确”和“状态同步”。不是等请求返回就立刻 emit，而是确保整个异步流程真正收尾——包括数据处理、错误判断、UI 更新准备就绪——再发出信号。

在子组件里：明确 loading 的起止点

loading 状态的生命周期必须与真实异步行为严格对齐：

1. 开始前立即 emit('loading-change', true)，比如点击按钮或 onMounted 触发请求时
2. 异步操作结束后（无论成功或失败），在 .then() / .catch() 或 try/catch 的 finally 块中调用 emit('loading-change', false)
3. 如果异步后还需执行 DOM 渲染或初始化（如 nextTick 后聚焦输入框），建议等这些也完成后 emit，避免父组件过早认为“已就绪”

在父组件里：接收并聚合 loading 状态

父组件不直接信任单个子组件的 loading，而是统一管理多个来源的状态：

1. 用 ref({}) 或 reactive(new Map()) 记录每个子组件的 loading 值，例如 loadingMap.set('form-panel', true)
2. 通过 computed 判断全局是否仍在加载：const isLoading = computed(() => Array.from(loadingMap.values()).some(Boolean))
3. 把 isLoading 绑定到遮罩层、按钮禁用或骨架屏上，实现视觉反馈一致性

配合语义化事件，让“结束”更有意义

单纯 loading-change: false 只说明“不忙了”，但父组件可能还想知道“是成功了？出错了？还是数据还没准备好？”：

1. 请求成功且数据可用了，额外 emit('ready')，父组件据此触发 scrollIntoView 或表单自动聚焦
2. 请求失败时，emit('error', { message, code })，由父组件统一展示提示或重试入口
3. 若需等待多个子组件都完成，可用 Promise.all 包裹它们各自的 ready 事件监听逻辑

注意两个常见坑

避免 loading 状态“假结束”或“卡住”：

1. 不要在 mounted 里盲目发 loading-change: true，此时可能还没发起请求
2. 不要只在 then 里发 false，漏掉 catch 就会导致 loading 一直挂着