在Webpack的构建流程中，每一个被处理的源文件都会经过解析与依赖收集阶段。编译器并不会等到代码运行才去知道一个模块输出了什么，而是在静态分析抽象语法树（AST）的过程中，就已经识别出export语句所声明的名称。这些名称最终被记录到模块对象的providedExports属性中，并在生成stats统计文件时对外暴露。对于需要精确掌握依赖关系、清理冗余打包内容的项目来说，这一字段比盲目搜索代码要可靠得多。
providedExports 的底层生成原理
Webpack在加载模块时，会调用对应的解析器（如javascript/auto）将源码转换为AST。遍历语法树时，遇到ExportNamedDeclaration、ExportDefaultDeclaration等节点，解析器就会提取其中的导出名。如果是命名导出，例如export const foo = 1，则foo会被加入该模块的providedExports列表；如果是重导出export { a } from './mod'，则a也会作为当前模块提供的导出被记录，同时触发对源模块的依赖追踪。
这种分析完全发生在编译期，不执行任何用户代码，因此即使导出值依赖运行时的环境变量，providedExports依然只反映语法层面向外暴露的绑定名称。它与usedExports字段不同，后者表示“被其他模块使用到的导出”，而providedExports只是“本模块声明了什么导出”。在Tree Shaking场景中，Webpack会交叉比对两者，将声明了但没人用的导出标记为可删除。
需要注意的是，动态导出如module.exports = {}配合运行时属性赋值，往往无法被静态分析捕获，这类模块的providedExports可能为空或者仅包含模糊的default推断。因此若要充分利用该字段，应尽量使用ES Module的静态export语法，而非CommonJS的动态写法。
如何在配置中开启并读取该信息
默认情况下，stats输出未必包含providedExports细节。你需要在Webpack配置中显式设置stats选项，或者在使用CLI时传入参数。下面是一段典型的配置示例，展示如何打开该字段并控制输出粒度：
// webpack.config.js
module.exports = {
// 其他配置省略
stats: {
providedExports: true,
// 同时可开启 usedExports 做对比
usedExports: true,
modules: true,
reasons: false
}
};
执行npx webpack --json > stats.json后，打开生成的stats.json，在modules数组的每个元素里，就能看到providedExports键。其值通常是一个字符串数组，列出了该模块导出的名字。若模块没有任何静态导出，该字段可能是空数组，或者在某些Webpack版本中直接缺失。
除了完整JSON，也可以借助webpack --stats verbose在终端中查看简要信息，但终端输出对大型项目不够友好。推荐将JSON导入自定义脚本，用Node读取并生成报表，例如筛选出providedExports为空却仍被打进主包的模块，作为清理候选。
实际应用场景与注意事项
在微前端或组件库打包中，providedExports可用于自动生成对外API文档。构建时扫描stats，提取每个入口文件的providedExports，就能知道包真正暴露了哪些接口，避免文档与代码脱节。相比人工维护导出列表，这种方式在重构频繁时优势明显。
另一个常见用途是依赖审计。当项目引入第三方库却只用其中一小部分时，对比库模块的providedExports与自身代码的usedExports，可判断是否存在大量未使用导出。虽然Tree Shaking能否剔除还取决于副作用标记，但providedExports至少给出了客观的声明清单，让优化讨论不再基于猜测。
使用时也要留意局限性。由于它依赖静态分析，被条件编译或eval包裹的导出不会出现在列表中；同时Webpack版本差异可能导致字段名称或结构微调，升级时建议用脚本做兼容读取。综上，stats.providedExports是一项低成本、高价值的编译期洞察工具，合理运用能显著提升依赖管理的确定性。
Webpackstats.providedExports模块导出分析修改时间：2026-08-22 22:42:42