webpack反编译

你拿到一个打包后的编译bundle.js，里面全是编译__webpack_require__和一堆数字模块ID。代码被压缩成一行，编译变量名短得跟密码似的编译。想改点逻辑？编译想看看某个功能怎么实现的？这时候就得靠反编译——或者说，把webpack打包产物还原成人类可读的编译形态。

别指望一键还原成原始源码。编译webpack的编译构建过程是有损的：Tree Shaking删掉的代码、作用域提升（Scope Hoisting）合并的编译模块、压缩工具干掉的编译注释，这些信息回不来。编译但你能做到的编译是：恢复模块结构，还原变量语义，编译理清依赖关系。编译够用了。编译

先看webpack的“指纹”

打开打包文件，搜索__webpack_require__。这是webpack运行时的核心函数，负责根据模块ID执行模块。老版本webpack（4及以前）用数组存模块，modules[moduleId]直接调用。新版本（5+）用对象或者Map，结构更清晰。

比如这样一段：

var __webpack_modules__ = {  "./src/utils.js": (function(module, exports, __webpack_require__) {  var _foo = __webpack_require__("./src/foo.js"); console.log(_foo.bar); }) };

看到没？模块路径直接写在键里。webpack5在开发模式下会保留路径，生产模式可能变成数字ID。数字ID也不是没救——结合__webpack_require__.m和__webpack_require__.c（模块缓存），能反推出模块间的调用链。

反编译工具怎么选

我常用webpack-decompile（npm包，虽然年久失修但还能跑）。它的思路是：解析AST，找到__webpack_require__调用，把模块ID映射回路径，然后把每个模块的函数体单独抽出来，生成独立文件。

另一个选择是dewebpack，支持webpack5，能处理作用域提升后的代码。不过它有时候会把__webpack_require__.n（获取默认导出）的调用搞乱，得手动修。

手动反编译也不难。打开Chrome DevTools，Sources面板里找到打包文件，点“Pretty Print”格式化。然后搜索__webpack_require__，在调用处打断点。运行页面，调用栈会告诉你模块之间的调用顺序。这招对定位特定功能特别管用。

一个真实案例

上个月帮朋友看一个加密的webpack打包文件。代码里用了eval动态执行字符串，常规反编译工具直接歇菜。我的做法：在eval外面包一层console.log，把字符串打印出来。结果发现是另一段webpack打包代码——套娃。

处理套娃得递归。先反编译外层，拿到内层的打包字符串，再对内层跑一遍反编译。两层下来，终于看到业务逻辑。里面有个_0x4f2a这样的变量名，明显是混淆过的。用AST工具把变量引用替换成_0x4f2a对应的字符串字面量，可读性立刻提升。

这件事说明：反编译不是纯工具活。你得理解webpack的运行机制，知道哪些信息可以恢复，哪些只能靠猜。有时候还得写点小脚本辅助。

反编译之后做什么

拿到还原后的模块，别急着改。先跑一遍npm install把依赖装上，然后对比原始打包文件的执行结果。如果行为一致，说明反编译正确。不一致？检查__webpack_require__.d（定义导出）和__webpack_require__.r（标记ES模块）的处理，这两个地方容易出错。

想修改逻辑？直接在还原后的代码上改，然后用webpack重新打包。前提是你得有完整的项目结构——package.json、webpack.config.js、入口文件。缺了这些，改完也跑不起来。

最后提醒一句：反编译别人的代码可能涉及法律问题。自己项目的打包文件随便折腾，商业软件的还是悠着点。技术无罪，用法有边界。

(责任编辑：焦点)