你一定能看懂的关于 devServer.publicPath、output.publicPath 和 output.path 的意义的阐述

经过一番测试，终于猜出了这几个字段合乎我测试结果的意义，暂时解决了它们给我带来的困惑，我打算先从 devServer.publicPath 这个字段说起，这样我觉得比较好讲明白一点儿，然后再说 output.publicPath 这个牵扯部分稍微多一点的字段，最后以最简单的 output.path 收尾。

devServer.publicPath

我们知道 devServer 这个字段只在 development 环境下有效，所以涉及到此字段的都是在 development 模式下。根据官方文档，这个字段的值是一个字符串，默认值为 '/'，它表示 devServer 这个服务器在以 contentBase 为根路径的基础上在 publicPath 这个路径上对外提供开发过程中 webpack 构建的文件，比如有一个文件名字是 vendor.dll.js，假定此时 devServer 跑在 http://localhost:8080 上，若我们不设置 devServer.publicPath 字段，同时也不要设置 output.path 字段的值（至于为什么，稍后会说到），那么我们访问 http://localhost:8080/vendor.dll.js 就可以访问到这个 js 文件，如图：

image.png

如果设置 devServer.publicPath 字段的值为 '/lalala/' 那么我们访问 http://localhost:8080/lalala/vendor.dll.js 就可以访问到该文件：

image.png

所以，这个字段的意义应该明晰了，即 决定外部能够以什么样的路径访问到构建的文件。

值得一提的是，devServer 构建的文件是在内存里的，而非你电脑的磁盘上，但是如果内存中找不到想要的文件时，devServer 会根据文件的路径尝试去电脑的磁盘上找，如果这样还找不到才会 404。所以如果我们把 devServer.contentBase 设置成 production 环境的 build 的目录时，那么如果这个目录上存在文件，这个文件就可以在 devServer 开启时通过对应的路径去访问。比如我现在 build/static/media 下存在 timg.fbfdb0cd.1.jpeg 这样一个文件，那么在我们把 devServer.contentBase 设置为 build 后，通过 devServer 访问 http://localhost:8080/static/media/timg.fbfdb0cd.1.jpeg 就可以得到该图片：

image.png

是一只柴犬。当然，通过一个服务器按照对应路径找到这只柴犬是必然的事情，这里突出的重点是，如果开发时在内存和 contentBase 下真实的磁盘路径中存在着同样文件名的文件，那么 devServer 返回的是内存的那个。

output.publicPath

这里也是一个 publicPath，那么肯定会想，这与上面的 devServer.publicPath 有关系吗？答案是：有。就像上面说的 devServer 把 contentBase 下真实的磁盘里的文件当做内存中文件的备胎一样，devServer 也把 output.publicPath 当做 devServer.publicPath 的备胎。就是说，如果后者，没有显式设定值，那么 devServer 就会尝试去读取前者的值，如果前者显式设定了值，那么就用前者的值，否则就用 devServer.publicPath 的 default 值，也就是 '/'；这就是我上面说的那会儿提到的在测试devServer.public的作用时不要给 output.publicPath 设值。那我们现在可以来看看只给 output.publicPath 设值而不给 devServer.publicPath 设值会发生什么，比如设定 output.publicPath: /kakaka/：

image.png

再看看同时给二者设定值会发生什么，比如设定 devServer.publicPath: /lalala/， output.publicPath: /kakaka/：

image.png

但是，这两个值设置成不一样会导致其他的问题，如图：

image.png

地址栏访问到的是 http://localhost:8080/lalala/index.html 但是这个 html 里的 script 标签以及一些其他的资源的前缀都是 'kakaka'，也就是说是以 output.publicPath 为准的，这就不得不提到 output.publicPath 的其他功能了：其实它不止是 devServer.publicPath 的备胎，更是其他的众多 loader 和 plugin 的备胎或者参考标准，比如 html-webpack-plugin 应该就是倚仗 output.publicPath 为构建的文件决定的满足特定需求的前缀来生成最终的文件访问路径给 inject 到对应的 html 模板中的。至于 webpack 对这个前缀要求的规则，webpack 官网教程里「配置」那一栏的 output.publicPath 就列的比较详细了。另外，这个字段的 default 值是一个空字符串 ''，如果没有特殊需求就设置 output.publicPath: '/' 好了。而且，如果可以的话，其他要用到这个字段的「东西」，最好不要把这个字段当初备胎，而把他当成唯一，这样应该会避免类似上面那样把两个 publicPath 字段的值设置成不一致而导致的问题。

总结

哎？是不是忘了什么？嗯，output.path 这个字段其实没什么好说的，它的意义应该不用再赘述了，实际上它只在 production 配置下有效，如果你去试一下的话，你会发现在 development 配置下，无论你给把它配置成什么值（前提必须是一个合规的绝对地址），它都不会对你访问开发时构建在内存中的文件产生影响，所以 development 配置下，直接忽略就好了。另外，它的 default 值是 path.resolve(__dirname, './dist')。

总而言之， devServer.publicPath 的意义就是决定外部能以怎样的路径通过 devServer来访问构建在内存中的文件，这个字段未显式设定时，则会去沿用 output.publicPath 字段的显式值（如果有的话，否则就用自己的 default 值）。output.publicPath 的意义是用来为构建的文件生成满足特定需求的前缀，并将这个前缀提供给需要的 resolver、plugin 或者其他的配置字段。

上面就是关于这两个让人光看 webpack 官网教程不一定能搞清楚其意义和用法的字段的总结，需要注意的是，这个总结不一定靠谱，因为它并不是出自翻阅源码（想翻过，太多了，不知道从何看起）之后的理论证实，只是在控制变量之后的再组合变量的多次测试猜想规律归纳而得。不过，至少他目前能解决我自己的困惑，所以，希望也能帮到有类似困惑的你。