webpack使用proxy代理时pathRewrite不生效的分析

写在前面

近日来，连续高压的做项目，都没时间来写点东西，今天浏览帖子时发现好多同学在问proxy使用pathRewrite重写路径时不生效的问题，一时兴起就想写篇文章告诉还不清楚的同学们。

概述前端打包工具

由于近些年来react、vue等MVVM框架的流行，使得前端的打包工具更倾向于webpack，相比传统的打包工具gulp，grunt等，webpack对于使用vue、react等构建的单页面应用有着超强的亲和力，再加上前端模块化的大趋势，webpack对于处理模块化有着天生的神力，由此webpack自然从众多的打包工具中脱颖而出。

直入主题pathRewrite

简单来说，pathRewrite是使用proxy进行代理时，对请求路径进行重定向以匹配到正确的请求地址，话不多说，上代码，我们先来看看不使用pathRewrite的配置：

proxy: {
  '/csdn': {
      target: 'https://blog.csdn.net',
      changeOrigin: true
   }
}

如上所示，我们现在想请求CSDN中某一个页面的某个接口，配置代理如上，请求代码附上：

axios.get("/csdn/u014427391/article/getSideArticles?                    
         pageindex=3&articleId=84980219&length=20")
         .then(function(response) {
           console.log(response);
         });

如上所示，我们简单的使用axios进行请求。实际上，我们要请求的接口地址是：“https://blog.csdn.net/u014427391/article/getSideArticles?pageindex=3&articleId=84980219&length=20”，配置代理"/csdn"对应的target为:"https://blog.csdn.net"，那么当我们不使用pathRewrite进行路径重定向的时候，加入我们像上述axios的代码那样进行请求时，我们代码中的GET请求是"/csdn/u014427391/article/getSideArticles?pageindex=3&articleId=84980219&length=20"，此时由于proxy的配置，此请求会被代理成"https://blog.csdn.net/csdn/u014427391/article/getSideArticles?pageindex=3&articleId=84980219&length=20"，显然可以看出，我们的请求地址中多了个"/csdn"，此时浏览器会报404错误，此时我们就需要用到pathRewrite重定向功能。

其实，不难看出，当我们配置了代理后，我们请求的地址前面会自动的加上我们所代理的地址，就上述我们的配置举个例子来说，就是，当我们代码中请求的地址是"/csdn/abc"的时候，我们真实请求的地址是"https://blog.csdn.net/csdn/abc"(前面会自动的加上我们所代理的地址)。

回归到最初的例子，当我们请求"/csdn/u014427391/article/getSideArticles?pageindex=3&articleId=84980219&length=20"时，我们实际上请求的是"https://blog.csdn.net/csdn/u014427391/article/getSideArticles?pageindex=3&articleId=84980219&length=20"，而真实的正确地址是"https://blog.csdn.net/u014427391/article/getSideArticles?pageindex=3&articleId=84980219&length=20"，由此发现多了个"/csdn"，由此导致浏览器报404的错误，所以由此分析，我们需要去掉请求路径中多余的"/csdn"，此时我们就需要用到pathRewrite进行路径的重定向了。直接上代码如下：

proxy: {
      '/csdn': {
        target: 'https://blog.csdn.net',
        changeOrigin: true,
        pathRewrite: {
          '^/csdn': '/'
        }
      }
    }

我们加了路径的重定向代码pathRewrite，上述代码以正则匹配规则将以"/csdn"开头的请求地址修改为""，也就是说，我们这样配置后，当我们请求"/csdn/abc"的时候，会被重写为请求"/abc"，直接在请求地址中将"/csdn"变成了""，由此刚好去掉了请求地址中多余的"/csdn"，由此，上述的404错误就得到了解决。

纯属个人理解，如有不同意见的大神，望指教。