Webpack构建完成后，我们常常通过stats配置输出各种编译信息，其中stats.publicPath这一项本意是告诉我们资源的基础路径。但不少同学在调试时发现，无论线上CDN怎么变，stats里打印出来的publicPath永远就是webpack.config.js中写的那个字符串。要弄清楚原因，得先理解Webpack内部对publicPath的处理机制以及stats模块的数据来源。
publicPath在Webpack中的两种存在形态
在Webpack的配置体系里，publicPath最直观的用法就是在webpack.config.js中写一个静态字符串，例如'/assets/'或者'https://cdn.ipipp.com/'。这种写法在编译启动阶段就被读入compiler配置对象，后续所有模块的资源路径拼接都以此为基础。这也是绝大多数项目采用的方式，简单且易于在构建时确定。
另一种形态是动态publicPath，常见于需要将资源托管到不同环境CDN的场景。开发者会在入口文件顶部通过__webpack_public_path__这个全局变量在运行时赋值，从而覆盖编译期的配置。例如根据用户所在区域动态切换CDN域名。这种写法并不会改变webpack.config.js里的publicPath字段，只是在产物运行时生效，因此编译期的统计信息自然无从感知。
需要特别区分的是，静态publicPath参与的是编译期的路径计算，而动态publicPath影响的是浏览器执行时的__webpack_require__.p值。两者作用的时机完全不同，这也直接导致了stats模块只能看到前者。很多误以为stats.publicPath会反映运行时地址的同学，正是混淆了这两个时机。
stats模块的数据读取逻辑
Webpack的Stats对象在收集信息时，主要依赖于compiler对象和compilation对象的内部状态。其中publicPath相关的输出，直接取自compilation.outputOptions.publicPath。而这个字段正是来源于配置文件中output.publicPath的静态值。即便你的代码里写了__webpack_public_path__ = 'https://x.ipipp.com/'，也不会反向写入outputOptions。
我们可以通过一段简化逻辑来看stats.publicPath的生成方式。在Webpack源码的Stats.js中，输出publicPath时大致等价于以下代码：
// 伪代码展示stats.publicPath来源
function getStatsPublicPath(compilation) {
// compilation.outputOptions来自webpack配置
const outputOptions = compilation.outputOptions;
// 直接读取配置中的publicPath，不做运行时追踪
return outputOptions.publicPath || 'auto';
}
// 假设配置为
const config = {
output: {
publicPath: '/static/'
}
};
// 即使运行时修改了__webpack_public_path__
// __webpack_public_path__ = 'https://cdn.ipipp.com/';
// getStatsPublicPath依然返回 '/static/'
console.log(getStatsPublicPath(compilation)); // 输出: /static/
从上面的逻辑可以看出，stats.publicPath本质上是一个配置回声，它忠实地反映了你在配置文件中写下的内容。如果配置里写的是'auto'，那么stats也会显示'auto'，表示Webpack会根据输出目录自动推导。这种设计保证了统计信息的确定性，不会因为运行时环境而产生波动。
有些团队希望通过stats.publicPath来校验线上资源是否指向了正确的CDN，结果每次构建都看到本地路径，就以为部署脚本出了问题。其实只要明白stats不追踪运行时变量，就能省去大量无谓的排查时间。若确实需要验证真实地址，应该在产物运行后通过浏览器网络面板或者服务端日志确认。
如何获取真实的资源公共路径
如果你希望在构建阶段就拿到可能被动态覆盖后的真实路径，就不能依赖stats.publicPath。一个可行的办法是使用compilation.getAssetPath方法，它允许你传入资源名并基于当前的publicPath规则计算完整地址。不过对于运行时才确定的值，编译期依然无能为力，只能退而求其次输出模板。
另一种更灵活的方式是编写自定义Webpack插件，在emit阶段读取资源文件内容，或者直接利用__webpack_public_path__的赋值语句做静态分析。例如扫描入口chunk中是否包含对全局变量的赋值，从而提示实际的publicPath策略。下面示例展示了一个简单插件，在构建结束时打印资源计算路径：
class PublicPathReporterPlugin {
apply(compiler) {
compiler.hooks.emit.tap('PublicPathReporterPlugin', (compilation) => {
// 使用compilation方法计算某个资源的路径
const calculated = compilation.getAssetPath(
compilation.outputOptions.publicPath || '',
{ hash: compilation.hash }
);
console.log('计算得到的publicPath前缀:', calculated);
// 注意：若运行时动态修改，此处仍只是配置值
});
}
}
module.exports = PublicPathReporterPlugin;
</code>
对于必须确认运行时地址的场景，推荐在应用启动后打印__webpack_require__.p的值。这个变量在浏览器里就是最终的publicPath，比任何构建期统计都准确。结合错误监控上报，你可以轻松发现CDN切换失败导致资源404的问题。
总结来说，stats.publicPath显示配置值不是Bug，而是Webpack明确的设计边界。理解配置期与运行期的划分，不仅能解释这个现象，也能帮你在资源路径相关的排障中少走弯路。当再次出现路径不符预期时，先确认你查看的是哪一层的信息，往往就能快速定位根源。
Webpackstats_publicPathpublicPath修改时间：2026-08-15 23:18:31