这个工具检查什么
如今仍有大量网站交付 webpack 产物,它的结构值得单独理解——区别于 JS 打包依赖可视化工具 所绘制的、与打包工具无关的通用依赖图。这个工具专门查找 webpack 打包产物的组成部分:
- 运行时启动代码——每个 webpack 构建都携带的
__webpack_require__形状的函数,通过它调用模块所用的确切机制(modules[moduleId].call(module.exports, module, module.exports, require))来检测,而不是搜索字面名称。这种机制能在标识符被完全重命名后依然生效,因此即使所有名称都被压缩,也能匹配到。 - 模块映射——无论是经典的对象形式(
{0: fn, 1: fn, ...})还是较新 webpack 版本默认采用的数组形式([fn, fn, ...])。 - chunk-push 元数据——对于代码分割的构建,
(self.webpackChunkXxx = self.webpackChunkXxx || []).push([[chunkIds], {modules}, runtime])调用,提取出代码块名称与 id。 - 运行时辅助方法——检测
.m(模块映射)、.c(模块缓存)、.d(定义 getter)、.o(hasOwnProperty)、.n(默认导出 getter)、.s(入口模块 id)、.p(公共路径)中哪些存在。
在列表中选择任意模块,即可在带语法高亮的面板中查看其真实源码——不执行任何代码,只是 webpack 本身包裹在该模块外层的文本。
当它不是 webpack 时
如果既找不到运行时也找不到模块映射,工具会给出**“这不像是 webpack 产物”**的提示,而不是强行猜测,并在可能的情况下附加一条简单诚实的线索——比如存在 //# sourceMappingURL= 注释,或该文件被解析为 ES 模块(Rollup、esbuild 和 Vite 的产物通常如此)。
已知局限
如果一个打包产物先经过 webpack,又经历了第二次更激进的压缩,连运行时自身的属性名也被重命名,就可能绕过 .call() 形态检测,被判定为“非 webpack”。这是刻意的取舍:偶尔出现的漏检,总好过凭空捏造一份根本不存在的模块映射。
隐私
一切都通过真正的 JavaScript 解析器(acorn)在你的浏览器中运行。你粘贴或上传的文件永远不会被发送到任何地方。
Tiny Online Tools







