Vue SPA中Axios拦截器控制Spinner引发重复请求致429错误排查

这个场景我之前碰到过类似的情况，核心问题大概率是修改响应式变量触发了组件重渲染，而重渲染过程中又重复执行了首页初始请求的逻辑——毕竟只执行console.log不会触发Vue的响应式更新，自然不会引发循环，一旦碰了响应式状态（比如修改showLoader或者调用Vuex action），就会触发连锁反应。下面是具体的排查步骤：

1. 先检查初始请求的触发位置是否存在重复执行的可能 #

这是最常见的原因，你需要确认首页的GET请求是在哪里发起的：

• 是不是写在了模板表达式里？比如<div>{{ fetchHomePageData() }}</div>，这种写法会导致每次组件渲染（包括响应式变量更新后的重渲染）都调用一次请求方法，直接引发无限循环。
• 是不是放在了计算属性里？计算属性应该是纯函数，不能包含请求这种副作用，否则每次依赖更新（比如showLoader变化）都会重新执行计算，触发请求。
• 是不是误写在了updated钩子中？updated会在组件每次重渲染后执行，如果这里面有请求逻辑，那showLoader的每一次变化都会触发新的请求。

正常来说，初始请求应该放在created或mounted钩子中，且只会执行一次——你可以临时加一个标记变量验证：

data() {
  return {
    showLoader: false,
    hasInitiatedRequest: false // 新增标记
  }
},
created() {
  // 拦截器配置逻辑...
  
  // 只在第一次加载时发起请求
  if (!this.hasInitiatedRequest) {
    this.fetchHomeData()
    this.hasInitiatedRequest = true
  }
}

如果这样修改后无限请求消失了，那就能确定问题出在请求被重复触发上。

2. 排查Axios拦截器与事件总线的逻辑是否存在循环触发 #

仔细检查你的拦截器代码：

• 是不是在request拦截器中发送show-loader事件后，某个监听showLoader变化的逻辑（比如watch）又触发了相同的请求？比如你可能不小心写了：

watch: {
  showLoader(newVal) {
    if (newVal) {
      this.fetchHomeData() // 这里会导致请求→showLoader=true→watch触发→再次请求的循环
    }
  }
}

• 确认响应拦截器是否正常触发hide-loader事件，如果请求完成后没有正确隐藏加载状态，会不会导致某个逻辑误以为加载未完成，重复发起请求？不过这个情况和你描述的“仅修改变量才出问题”不太吻合，但也可以排查下。

3. 检查事件总线的监听是否重复绑定 #

如果你把eventBus.$on('show-loader', ...)写在了mounted或created钩子中，却没有在组件销毁时用eventBus.$off解绑，那么每次组件重渲染（比如路由切换后回到首页）都会新增一个监听回调。虽然这不会直接导致无限请求，但会让showLoader的修改逻辑执行多次，加重问题，甚至间接触发其他副作用。

4. 排查Vuex Action的副作用（如果用了Vuex） #

如果是调用Vuex Action后出现的问题，要检查：

• 这个Action是否间接触发了首页请求？比如Action修改了某个state，而你在组件中watch了这个state，watch回调里又发起了请求。
• Action本身是否包含了请求逻辑，且这个Action被showLoader的变化间接触发了？

5. 用Vue DevTools做可视化排查 #

打开Vue DevTools，通过这几个面板定位问题：

• Events面板：观察每次showLoader变化时，有没有额外的事件被触发，比如fetch相关的事件。
• Components面板：查看App.vue或首页组件的渲染次数，如果渲染次数和请求次数一致，说明重渲染确实触发了请求。
• Network面板：对比请求触发的时间点和showLoader更新的时间点，确认两者的关联。

内容的提问来源于stack exchange，提问作者ankush981