uni-app uni.addInterceptor

uni-app uni.addInterceptor

示例代码：

uni.addInterceptor(‘request’, { invoke(args) { // 请求前触发 },
returnValue(args) {
},
success(res, obj) {
},
fail(res, obj) {
},
complete(res, obj) {
}
});


## 操作步骤：

- 只要拦截了，云函数访问就会出现问题，判断放行也不行。

## 预期结果：

- 云函数要和 `uni.addInterceptor` 分离，不允许拦截

## 实际结果：

- 只要拦截了，不管怎么处理，云函数访问都报错

## bug描述：

- 只要添加了 `uni.addInterceptor`，云函数的访问就会出现问题，判断放行也不行，能不能把这个拦截和云函数分离？

更多关于uni-app uni.addInterceptor的实战教程也可以访问 https://www.itying.com/category-93-b0.html

2 回复

出现什么问题呢？

更多关于uni-app uni.addInterceptor的实战教程也可以访问 https://www.itying.com/category-93-b0.html


uni.addInterceptor 的拦截范围确实包括云函数请求，这是当前框架的设计机制。当拦截器被注册后，所有通过 uni.request 发起的请求（包括云函数调用）都会经过拦截器处理。

从技术实现角度看，云函数请求本质上也是基于 uni.request 封装的，因此无法通过配置直接排除云函数拦截。不过可以通过以下方式实现区分处理：

在拦截器的 invoke 方法中，可以通过判断请求的 URL 或特定标识来区分普通请求和云函数请求：

uni.addInterceptor('request', {
    invoke(args) {
        // 通过 URL 特征判断是否为云函数请求
        if (args.url.includes('/cloudfunctions/') || 
            args.url.includes('uniCloud')) {
            // 云函数请求直接放行，不进行拦截处理
            return;
        }
        
        // 普通请求的拦截逻辑
        console.log('拦截普通请求:', args.url);
    }
});

或者通过自定义请求头标识：

// 云函数调用时添加特定标识
uniCloud.callFunction({
    name: 'functionName',
    data: {},
    header: {
        'X-Request-Type': 'uniCloud'
    }
});

// 拦截器中判断
uni.addInterceptor('request', {
    invoke(args) {
        if (args.header['X-Request-Type'] === 'uniCloud') {
            return;
        }
        // 其他拦截逻辑
    }
});
回到顶部