修改几个地方：

所有的资源，前缀都带上了 /。没错，这就是 publicPath 的效果。目前我们测试的域名是 http://public_path.com/ 那假如有一天，老板让我们改一下 URL，需要访问 http://public_path.com/vue/ 才是访问我们当前的页面，你会怎么处理？

熟悉 nginx 的同学应该有答案了，因为域名指向了 /dist/ 文件夹，URL 其实和我们资源管理器是一个道理，我们只需要嵌套文件夹，URL 就能一路找下去，所以我们把项目的文件夹调整下

再次访问 http://public_path.com/ 效果如下：

进入 vue 文件夹内

是 nginx 出错了吗？不是的，是资源路径错了。因为在 index.html 中，我们引入的 JS 资源是 / 开头的，意思就是会无视 URL 的层级，直接从最顶级开始找文件，这当然找不到了

publicPath:’/’ 第一个弊端出现了： 就是迁移项目/遇到 URL 复杂的项目的情况下，很容易就找不到资源

因为 ./ 和 '' 在打包完成后对于相对路径来说是一个效果，所以我们用相对清晰的./做演示

修改几个地方：

• http://public_path.com/ 项目中，图片没显示，是因为我的 webpack 配置了 css 文件分离，不过我的图片也是分开打包到了assets/images/ 目录下。分离后，图片的引入还是用的相对路径 ./

可以对比一下使用 img 标签引入的图片和 css 引入的图片的路径差别。可以看出 css 引入的图片中，URL 多了一个css

和 nginx 原理差不多，原先是指向到 dist 文件夹中的，可是配置 publicPath 后，指向的文件夹往上走了一层，所以就可以看到包括 dist 文件夹在内的目录

这部分的资源和 http://public_path.com/ 解释是一样的了，因为相对路径的问题，所以多了一层 css

是不是使用 ./ 就会有那么多问题呢？继续看下更换目录的情况

和之前一样，多加一层 vue 文件夹，访问 http://public_path.com/vue/

没错，比起空白页，这个起码更换目录结构，资源还是都可以请求的。因为使用 ./和'' 访问的都是相对路径，并非绝对路径，只要index.html和资源文件夹的相对路径没改变，项目随便迁移。

不信可以在迁移一层：

publicPath:’./'弊端： 如果 webpack 配置了样式分离，尤其是 vue 这种 css 和图片都分开文件夹存放的情况下，特别容易出问题
publicPath:’./'好处： 迁移项目的时候，因为用的都是相对路径，所以不管 URL 怎么变化，基本都能找到相应的资源

上面的大量截图和 demo，可以看出，publicPath:'./' 就差在了 css 打包的时候，因为 css 分离，多了一层文件夹，而图片也分离了，不在 css 文件夹下才导致的。而 publicPath:'/' 呢，刚好都是让资源直接从根目录开始找。
那么我们只需要解决 图片文件和 css 文件夹中的关系，第一个问题就解决了
实际上呢，项目是自己搭建的，css 和图片输出的地方也是我们控制的，我们只需要在处理 css 的图片的时候，处理好publicPth就行，不过也不能直接用 /，因为还是迁移项目的那个问题，我们可以考虑使用 ../ 图片和 css，就差了一层文件夹嵌套！为啥？因为 css 和图片输出的地方也是我们控制的，细细想想，是不是这么个道理？（针对这个 webpack 是这个道理，不同项目，分别讨论~，原理是一样的）

还有一个就是 publicPath:'./' 在本地开发的时候，打开的都是目录，加 /dist/ 访问总觉得的欠妥。
那就用 webpack 的多环境配置，在 dev 环境下还是用 / 保证 localhost 可以正常打开，实际打包的时候在改用 ./

• webpack.base.js
  • 修改 output.publicPath 为 './'。(不过这个影响不大了，因为都会被后面的配置覆盖)
  • 修改 MiniCssExtractPlugin.loader 里面的 publicPath 为 ../
• webpack.dev.js
  • 修改 output.publicPath 为 '/'。
• webpack.prod.js
  • 修改 output.publicPath 为 './'。

重新打包，重新运行

url 访问：

localhost 访问：

添加 vue 文件夹在访问：

只能说一句：完美~

开始的时候 vue-cli 的配置还给出了一种 publicPatch 为 /my-app/ 的场景。其实这个场景和我们使用 vue 文件夹的场景特别相似。我们也可以模拟一下。

这种场景什么时候会遇到呢，就是在已经固定的文件夹下再去放项目，比如码云的 gitee pages。目前我的博客就是运行在码云的 gitee pages 上，码云给我分配的链接是 http://jioho.gitee.io/blog/ ，那么这时候我的 publicPath 就需要是 blog了。

改一下文件：

• webpack.base.js
  • 修改 output.publicPath 为 '/my-app/'。(不过这个影响不大了，因为都会被后面的配置覆盖)
  • 修改 MiniCssExtractPlugin.loader 里面的 publicPath 为 /my-app/
• webpack.dev.js
  • 修改 output.publicPath 为 '/my-app/'。
• webpack.prod.js
  • 修改 output.publicPath 为 '/my-app/'。

然后重新运行和重新打包，看下效果：

• index.html 不出所料，就是把 /my-app/加在前面了。所以 css 资源和图片资源也不例外

既然指定了前缀，那使用本地开发的时候也是少不了需要添加 /my-app/

包括我在写自己博客本地预览的时候，vuepress 一样会把blog帮我带上

像这种情况呢，nginx 可能会做一些反向代理，或者重定向之类的操作_{倒不是说不会写这部分配置，只是已经超出今天讨论的范围，配置我就不去调试了}

像这种平台原先指定好了 /my-app/ 前缀让你部署一个项目的话，其实用 './'+css 资源使用 '../' 的这套方式可以打遍天下~前提是这个 webpack 是你自己搭建的，如果用的还是 vue-cli 或者像我一样在用 vuepress 没有自己去搭自己的 webpack，那就只能把 publicPath 传进去让程序内部处理了~

publicPath 的 3 种情况

• 好处：可以部署到任意域名下，因为用的相对路径，只要整个项目迁移，就不会出问题
• 弊端：前提是这套脚手架/webpack 能支持 ./ 这种情况，如果遇到常见的 css 分离，image 文件夹单独分离的情况，那就得看内部处理了，我想 vue-cli 也是和我的处理方式差不多把，毕竟打包后的资源放哪里，都是 vue-cli 说了算~

• 好处：不用考虑太多资源性的问题，基本上打包出去后都能从根目录开始查找，webpack 打包后资源多数也是从支持根目录开始找
• 弊端：项目迁移的时候就 GG 了，必须部署在域名，紧跟着 .com/.cn … 后面，不能在多插入任何的路由前缀

这个谈不上好处和弊端，因为这是平台的限制，无法突破，只能服从 😃