emit不适合全局loading反转，因其仅为父子单向通信机制，无法支持跨层级、多源并发下的状态聚合与防抖；正确做法是拦截器驱动pinia计数器，emit仅作局部语义化反馈。
直接用 emit 实现“全局 Loading 状态反转”是不合适的。Emit 是父子组件间单向、短链路的通信机制，它无法天然支持跨层级、多来源、异步并发下的状态聚合与反转（比如多个请求中一个结束、一个还在跑，此时 loading 应该保持 true，而不是被某个子组件 emit false 就关掉）。真正的状态反转逻辑，必须由统一的状态源控制，emit 只能作为触发信号或辅助反馈，不能承担主责。
为什么 emit 不适合做全局 loading 反转
全局 loading 的本质是“当前是否有任意请求正在进行”。这需要计数、聚合、防抖、异常兜底——这些能力 emit 本身不具备：
- emit 事件需手动逐层监听+透传，父组件一漏听，状态就断；
- 多个子组件同时 emit 'hide-loading'，会互相覆盖，导致遮罩提前消失；
- 请求失败、超时、取消等边界情况，emit 很难保证每次都有对应 “反转” 事件发出；
- 没有时间维度管理，无法判断“哪个 loading 该关、哪个还该留”，即缺乏上下文。
正确做法：拦截器驱动 + 状态中心反转
把 loading 的启停交给请求拦截器，把“是否显示”的判断权交给 Pinia store，emit 仅用于局部反馈（如某按钮点击后通知父组件更新自身 loading 状态）：
- Axios 请求拦截器中调用
loadingStore.start()，响应拦截器（含 error）中调用loadingStore.done()； - Pinia store 内部用计数器（
count）管理，start()自增，done()自减，isLoading派生为count > 0； - 组件中通过
v-if="loadingStore.isLoading"控制遮罩显隐，完全解耦 emit； - 若某子组件需单独控制自己的加载态（如上传进度条），可 emit 语义化事件如
upload-start/upload-progress，父组件监听后更新局部 ref，不影响全局计数。
emit 可以怎么配合使用（有限但实用）
在明确父子关系、且 loading 与组件生命周期强绑定的场景下，emit 能提供清晰的意图表达：
- 子组件提交表单前：
this.$emit('loading-start', 'submit')； - 父组件监听后设置
localLoading = 'submit'，并禁用按钮； - 请求完成（无论成功失败）后，子组件 emit
'loading-end'，父组件重置； - 这种模式不干扰全局状态，只服务于 UI 响应节奏，适合弹窗、抽屉等临时性操作。
避免常见陷阱
实际开发中容易踩的坑，往往源于混淆了“触发动作”和“维护状态”：
- 不要在组件里写
this.$emit('toggle-loading')—— toggle 是状态操作，不是事件语义； - 不要让多个子组件都 emit 'show-loading'，然后靠父组件用布尔值合并 —— 这等于自己造了个不可靠的简易计数器；
- 拦截器中关闭 loading 必须用
finally或统一响应处理，不能只在then里关，否则错误请求会导致 loading 卡住； - 如果用了
AbortController主动取消请求，也要同步调用loadingStore.done()，否则计数失准。
