webpack/vue-cli 中的 publicPath / 和 ./ 的区别

在说这个问题之前，vue-cli 的配置文档已经说的非常清楚了 publicPath

而 webpack 对于 publicPath 的描述相对苍白。但是 vue-cli 对于我们来说也是一个黑盒子，我们只知道 publicPath 可以配置'',./ 或者 /my-app/ 这种自定义 URL。但是，你真的理解 webpack 里面的 publicPath 吗？

准备环境

nginx 模拟一个真实的 URL 和高仿真项目
webpack 自己写一段 webpack，并且复现对应的场景

（webpack 的配置说复杂也复杂，说简单也简单，如果不想自己从头开始写的，可以从我的一个仓库中直接获取演示代码webpack_config
因为我就是在写这段配置的时候深入研究的 publicPath

PS：如果用我的 webpack 仓库，把代码拉下来后，记得看下是不是在 v0.0.2 分支！

如果对于 nginx 和 webpack 实在太陌生，可以看下后续的描述把~

环境的配置

nginx.conf nginx 配置不复杂，给他分配一个域名，指向 80 端口，指定入口文件，入口文件下可以直接找到 index.html 即可

server {listen        80;server_name  public_path.com;root   "E:/Desktop/publicPathDemo/webpack_config/dist";location / {index index.html index.php;autoindex  on;if (!-e $request_filename) {rewrite  ^(.*)$  /index.php?s=/$1  last;break;}}
}

修改 host 文件，添加一个域名

127.0.0.1 public_path.com

在准备好的 webpack 项目中，打包一份 dist 文件出来

一切准备就绪，访问 public_path.com

环境准备完毕，开始探究 publicPath

publicPath 使用 ‘/’ 的情况

修改几个地方：

webpack.base.js
- 修改 output.publicPath 为 '/'。
- 修改 MiniCssExtractPlugin.loader 里面的 publicPath 把他注释掉
webpack.dev.js
- 修改 output.publicPath 为 '/'。
webpack.prod.js
- 修改 output.publicPath 为 '/'。
然后运行 npm run build 更新一份打包
运行 npm run serve 运行一份开发环境的情况。打开浏览器的 http://localhost:8080/

圈重点

index.html

css 中图片的资源

localhost 中 css 的情况

更换项目的 URL

所有的资源，前缀都带上了 /。没错，这就是 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 复杂的项目的情况下，很容易就找不到资源

publicPath 使用 ‘./’ 或者 ‘’ 的情况

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

修改几个地方：

webpack.base.js
- 修改 output.publicPath 为 './'。
- 修改 MiniCssExtractPlugin.loader 里面的 publicPath 把他注释掉
webpack.dev.js
- 修改 output.publicPath 为 './'。
webpack.prod.js
- 修改 output.publicPath 为 './'。
然后运行 npm run build 更新一份打包 (build 的时候会自动清空dist目录，然后重新生成文件)
运行 npm run serve 运行一份开发环境的情况。打开浏览器的 http://localhost:8080/

老规矩，看几个文件：

index.html

css 文件中的资源

localhost 中的情况

localhost 中进入 dist 目录看看

为什么 http://public_path.com/ 的图片不显示了

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

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

localhost 为啥打开是文件夹目录了?

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

localhost 中进入 dist

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

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

更换项目的 URL

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

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

不信可以在迁移一层：

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

能不能 publicPath 在’/‘和’./’ 互相取长补短？

可行性在哪里？

上面的大量截图和 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 文件夹在访问：

只能说一句：完美~

另外一种 /my-app/ 的场景

开始的时候 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 … 后面，不能在多插入任何的路由前缀

自定义 .com 后面的域名

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