interceptors(拦截器)的具体适用场景及不可使用场景分别有哪些？

除授权流程外的常见适用场景 #

• 统一公共参数注入：所有请求都需要携带的通用参数（比如设备标识、客户端版本号、全局统一签名、时间戳等）都可以在拦截器中统一追加，无需每个业务请求手动编写，例如在axios请求拦截器中直接修改config.headers或者config.params即可实现。
• 响应数据统一预处理：后端返回统一格式的响应结构体时，可以在响应拦截器中提前剥离外层包装，直接返回业务需要的data字段，省去每个接口重复解构的代码；还可以统一处理通用错误码，比如返回401直接跳转登录页、返回500统一弹出全局报错提示，无需每个请求单独写catch逻辑。
• 请求全链路日志埋点：需要统计接口请求耗时、成功率、错误类型等运维/产品数据时，拦截器可以统一采集上报，不用每个接口单独埋点。
• 重复请求拦截与防抖：针对用户短时间重复提交、网络抖动导致的重复请求，可以在拦截器中通过「请求方式+请求URL+请求参数」生成唯一标识，拦截pending状态的重复请求，避免脏数据。
• 通用缓存逻辑处理：针对返回结果不常变化的GET类静态接口，可以在拦截器中统一做本地缓存，相同请求第二次发起时直接返回缓存结果，降低服务器压力。
• 动态域名/路径适配：多环境部署、多业务域名拆分的场景下，可以在拦截器中根据规则动态替换请求域名、统一拼接接口前缀，无需业务侧感知。

不适合使用拦截器的场景 #

• 强绑定单一业务的特殊逻辑：仅单个/极少数接口需要的定制化处理，比如特定活动接口返回专属错误码时跳转活动落地页，不要放到拦截器中，会导致拦截器逻辑越来越臃肿，后期维护成本指数级上升。
• 依赖业务上下文的个性化处理：部分接口的错误提示、响应处理需要结合当前页面的业务场景做定制化实现，放在拦截器中会覆盖业务侧的自定义逻辑，反而增加适配成本。
• 有严格顺序依赖的异步逻辑：如果多个请求的处理逻辑存在强先后依赖关系，全局拦截器的处理很容易打乱执行顺序，导致逻辑异常。
• 小范围适用的特殊加解密：仅支付、隐私数据等少数接口需要的独立加解密逻辑，不要放到全局拦截器，既会增加普通请求的不必要性能开销，也容易导致敏感逻辑泄露。

是否所有请求都可以直接接入拦截器 #

并不建议所有请求都直接接入全局拦截器，最好提前配置白名单/黑名单规则做区分：

• 登录、获取验证码这类不需要携带token的公共接口，可以放到白名单中跳过授权类拦截逻辑。
• 第三方跨域请求、大文件上传/下载类特殊请求，如果不需要适配内部公共规则，也可以单独配置跳过拦截器。

核心判断标准：拦截器只适合处理通用的、和业务无关的公共逻辑，如果某类逻辑的适配请求占比低于10%，就不要放到全局拦截器中。

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