如何在Axios拦截器处理服务端自定义验证错误及对接React Query与Redux？

场景背景 #

我在实现用户注册功能时，已在客户端调用API前完成验证，服务端也会进行二次验证（如邮箱已存在、手机号无效、确认密码不匹配），并返回带状态码和信息的自定义错误：

return StatusCode(451, "Email ID already exists"); 

在Axios响应拦截器中接收该错误时，若返回return Promise.reject(error);会触发控制台报错；若返回return error，则错误会进入AddUser函数的response而非catch块：

axios.interceptors.response.use(function (response) {
    //...
    return response;
  }, function (error) {
    // 非2xx状态码触发此函数
    // 此处接收错误：Email ID already exists
    return Promise.reject(error);
  });

我的AddUser函数通过try/catch捕获错误后，再次reject给React Query的useMutation：

async function AddUser(user) {
    try {
        const response = await axios.post("/Auth/register", user)
        console.log(response)
    } catch (error) {
        console.log(error.response.status)   // 451
        console.log(error.response.data)     // Email ID already exists
        return await Promise.reject(error)   // 控制台再次报错
    }
}

useMutation的调用代码如下：

export const apiAuthRegister = ({onError}) => {
    const navigate = useNavigate();
    return (
        useMutation({
            mutationKey: ['authRegister'],
            mutationFn:  (user) =>  AddUser(user),
            onSuccess: (data) => {
                //....
            },
            onError: (error) => {
                console.log('REGISTER FAILED')
                console.log(error)  // Email ID already exists
                onError(error.response.data)    // 更新输入框错误提示
            }
        })
    )
}

疑问解答 #

1. 当前这种处理服务端自定义错误的方式是否合理？ #

整体逻辑通顺，但有两处可优化：

• 拦截器里Promise.reject(error)触发控制台报错是正常行为——浏览器会输出未被捕获的Promise reject，但你在AddUser的catch里捕获错误后又再次reject，相当于重新抛出错误，所以控制台会再次报错。其实这里不需要return await Promise.reject(error)，直接throw error即可，效果一致且更简洁，还能避免不必要的await嵌套。
• 这种层层传递错误到React Query的onError的方式是合理的，因为React Query的mutation本身就设计通过onError处理错误状态，能自然和组件的错误提示逻辑结合。

2. 是否应该返回特殊状态码（如151）作为响应，再传递给Axios和useMutation？ #

不建议这么做。HTTP状态码有明确语义规范：

• 4xx状态码专门用于表示客户端错误（比如邮箱已存在用409「资源冲突」更符合规范，而非自定义的451），服务端应遵循规范返回对应状态码，而非自定义非标准的1xx状态码（1xx属于信息性响应，和错误无关）。
• 使用标准状态码的好处是Axios能自动识别并触发错误拦截器，前端生态里的其他工具也能正确识别错误类型，减少不必要的自定义逻辑。

3. 能否直接在Axios拦截器中将错误存入Redux Store的error-slices，替代当前层层传递的方式？该方案是否为最佳实践？ #

可以实现，但不是最佳实践：

• 可行点：拦截器是全局捕获HTTP错误的入口，在这里把错误存入Redux确实能减少重复的错误传递代码。
• 问题点：
  • 耦合性过高：所有HTTP错误都会存入Redux，但不同业务场景（注册、登录、数据获取）的错误处理逻辑可能不同，全局存Redux会导致错误状态混乱，难以区分归属请求。
  • 与React Query设计冲突：React Query本身已维护mutation的错误状态，同时存到Redux会造成状态冗余，增加维护成本。
  • 灵活性不足：如果某个请求需要特殊错误处理逻辑，全局拦截器存Redux的方式很难定制。

最佳实践仍是让React Query的onError处理业务相关错误，因为它能精准绑定到对应mutation，错误状态与请求生命周期强关联，更符合React组件化思维。

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