别让请求乱飞：Axios 拦截器的实战配置指南

接手老项目时，最让人头大往往不是接口联调，而是翻开源码看到几十处重复的 headers 拼装和散落在各组件里的 catch。每次发请求都手动塞凭证，报错时页面直接跳出原生 alert，开发体验和运维成本直线下降。把通用逻辑收口到拦截器里，才是把时间还给自己和业务的手段。

Axios 拦截器本质上就是个请求过闸机。请求发出前拦截一次，响应回来后清洗一次。基础写法框架固定，但真正拉开差距的在于细节取舍。

import axios from 'axios';
const instance = axios.create({ baseURL: '/api', timeout: 10000 });

instance.interceptors.request.use(config => {
  const token = localStorage.getItem('access_token');
  if (token) config.headers.Authorization = `Bearer ${token}`;
  return config;
}, error => Promise.reject(error));

instance.interceptors.response.use(
  response => response.data,
  error => Promise.reject(error)
);

这段骨架能跑通基础场景。往下挖，需要解决三个实际痛点。

动态凭证挂载要留退路。 纯靠 localStorage 强耦合容易埋雷。建议在 config 上挂载元数据标识，例如此类公开路由或第三方直传不需要鉴权，拦截器里加一句 if (config.metadata?.skipAuth) return config;。业务调用时传入 { url: '/upload/file', metadata: { skipAuth: true } } 即可，请求字典清晰不污染头部。

错误对象必须做一层清洗。 拦截器原样抛出的 error 携带大量 axios 内部属性，组件层根本用不到。顺手接住报错做结构化转换，调用方直接拿业务提示：

const parseHttpError = err => {
  if (!err.response) return { code: -1, msg: '当前网络不可达' };
  const { status, data } = err.response;
  if (status === 401) throw new Error('登录态已过期，请重新登录');
  return { code: data.errCode || status, msg: data.errMsg || '服务异常，请稍后重试' };
};

主流程捕获时只取 msg 渲染 Toast，底层网络波动不会撑爆 UI 代码。

401 并发刷新防雪崩。 令牌过期时如果在拦截器里直接执行重刷逻辑，极易触发请求排队甚至死锁。稳妥的做法是维护一个执行队列：首次捕获 401 时挂起后续同类请求，拿到新凭证后按序派发；若超过两秒未返回则主动中断队列降级处理。配合全局状态标记，能把瞬间放大的请求峰值掐灭在网关外。

拦截器不是兜底代码库，塞得越满越难排查。保持单一职责，把身份注入、响应清洗、异常降级拆成独立函数，日常迭代时才不会被半夜跳出来的告警牵着鼻子走。把一扇门修严实，远比在屋里铺十张地毯来得省心。