简介：这份 wxappUnpacker 小程序反编译工具包面向需要解析微信小程序主包与分包结构的开发者、安全研究人员及进阶学习者，用于将小程序包中的 WXML、WXSS、JS、JSON 等文件还原为可读源码，便于分析业务逻辑、排查问题、做性能优化与安全审计。压缩包共 780 个文件，约 1.97MB，以 374 个 js 脚本、83 个 json 配置、71 个 md 文档、70 个 ts 文件及 61 个 map 文件为主，并含 license、ps1、cmd 等依赖与命令行辅助文件，目录较完整地保留了工具运行所需模块。已有 270 人学习下载，可作为研究小程序逆向流程与代码结构的参考。借助包内脚本、说明文档和配置示例，读者可了解主包/分包处理、代码美化与依赖组织方式，并据此搭建自己的分析环境。

1. 从一次包体排查说起：wxappUnpacker 到底解的是什么

小程序反编译听着玄乎，落到实际工作上往往很具体：线上某个页面只在部分机型白屏，本地分支切了七八个都对不上上传的那份包，手里只剩一个 .wxapkg 文件。wxappUnpacker 就是冲这个场景写的一套 Node 脚本，它把打包产物拆回 app-config.json、app-service.js 和各页面的 wxml、wxss、json，让你能拿着拆出来的东西跟源码逐行对。

它适合两类人：一类是接手别人项目、手上没有源码的开发者，想弄清某个交互到底怎么写的；另一类是想搞明白小程序打包过程做了哪些转换、准备自己写构建插件或检查工具的熟手。需要先把预期立住——它做的是还原，不是复原。压缩和转译造成的信息损失补不回来，变量名回不去，注释更回不去，能拿回的是结构、路径、配置和大致逻辑。把它当成一台能看清骨架的 X 光机，而不是一台时光机。

2. 目录与解包链路：一个 wxapkg 进来，一堆文件出去

这个项目的体积很小，小到第一次打开会怀疑是不是下错了。根目录没有 src、没有 dist，就是几个平铺的脚本加一个 package.json。这种结构在小工具类项目里很常见，好处是改起来直观，坏处是没有分层，读之前得先知道谁调谁，否则打开入口文件会被一堆分支绕晕。

2.1 仓库里都有哪些脚本，谁调谁

各分支的命名可能有增删，但主干基本固定，读源码前先把这张表在脑子里建起来，后面看调用链会顺很多。

入口脚本承担的事情比想象中多：它既要处理命令行参数，又要负责把 wxapkg 里的原始字节落到磁盘，还要在落盘之后判断哪些文件该交给还原器、哪些直接写出去就行。真正做还原的三个模块反而很纯粹，输入是字符串，输出还是字符串，不碰文件系统。这种「入口管 IO、还原器管转换」的切法值得学，你后面想加自己的处理步骤，挂在入口的分发环节最省事，不用改还原逻辑。

需要注意的是这份脚本集没有统一的状态管理，输出目录、是否覆盖、是否跳过还原这些开关，基本靠入口函数里的局部变量一路往下传。读的时候建议从入口的 main 往下跟一遍，把参数最终落在哪个函数里记下来，比自己猜要快。

2.2 wxapkg 的文件结构：魔数、索引段和数据段

wxapkg 不是什么复杂容器，本质上就是「头部 + 索引 + 数据」三段式。头部定长，开头和结尾各有一个固定标记字节，中间夹着索引区长度和数据区长度两个 32 位整数；索引区是一串变长条目，每条记录文件名长度、文件名、数据偏移、数据长度；数据区就是所有文件内容首尾相接。

字段顺序以脚本里的读取逻辑为准，不同版本可能对保留字段的处理有差异，但下面这段读取流程能覆盖绝大多数情况：

const fs = require('fs'); // 读取 wxapkg 的头部与索引区，返回每个文件在数据区中的位置 function readIndex(file) { const buf = fs.readFileSync(file); let p = 0; const firstMark = buf.readUInt8(p); p += 1; // 固定起始标记，用来快速判断是不是合法包 const info1 = buf.readUInt32BE(p); p += 4; // 保留字段，多数实现直接跳过 const indexLen = buf.readUInt32BE(p); p += 4; // 索引区总字节数 const bodyLen = buf.readUInt32BE(p); p += 4; // 数据区总字节数 const lastMark = buf.readUInt8(p); p += 1; // 固定结束标记 const indexEnd = p + indexLen; const files = []; while (p < indexEnd) { const nameLen = buf.readUInt32BE(p); p += 4; const name = buf.slice(p, p + nameLen).toString('utf8'); p += nameLen; const offset = buf.readUInt32BE(p); p += 4; // 相对数据区起点的偏移，不是文件绝对位置 const size = buf.readUInt32BE(p); p += 4; // 该文件的字节长度 files.push({ name, offset, size }); } return { firstMark, lastMark, bodyStart: indexEnd, bodyLen, files }; }

这段代码有几个点值得留意。所有整数都是大端序读取，用readUInt32BE而不是readUInt32LE，写错了会读出天文数字然后切片越界。偏移量是相对数据区起点的，落盘时要用bodyStart + offset去切，直接用 offset 会切到索引区里。索引区的遍历条件是p < indexEnd，而不是读到文件末尾，因为数据区紧跟在后面，边界一旦算错，最后几个文件就会变成乱码。

理解了这个结构，很多现象就解释得通了。解出来的文件全是 0 字节，说明索引读到了但数据区切片位置不对；报「越界」通常意味着包被截断或者头部字段被改过；只有前几个文件正常、后面全是乱码，多半是某个条目的长度字段对不上，导致后续偏移整体错位。遇到这类问题，先打印indexLen、bodyLen和文件实际大小三者之间的关系，比盲改代码有效得多。

2.3 从入口到产物：一次解包的完整调用顺序

主流程可以拆成四步：读索引、按索引落盘、按后缀分发、收尾补配置。第三步是整个项目最核心的设计，用一个后缀到处理函数的映射表把不同类型的文件分流，新增一种文件类型只要往表里加一行，不用动主循环。

// 主控里的分发逻辑：不同后缀走不同处理路径 const handlers = { '.js': (text, out) => unpackJs(text, out), // 交给 AST 还原，拆模块、重排版 '.json': (text, out) => writePrettyJson(text, out), // 配置类，格式化后直接落盘 '.wxml': (text, out) => unpackWxml(text, out), // 处理换行、缩进、标签配平 '.wxss': (text, out) => unpackWxss(text, out), // 展开压缩后的样式规则 }; for (const item of files) { const buf = readSlice(item); // 从数据区切出该文件的原始字节 const ext = path.extname(item.name).toLowerCase(); const out = path.join(outDir, item.name); fs.mkdirSync(path.dirname(out), { recursive: true }); const handler = handlers[ext]; if (handler) { handler(buf.toString('utf8'), out); } else { fs.writeFileSync(out, buf); // 图片、字体等二进制资源原样写出 } }

分发环节有两个容易被忽略的细节。一是必须先mkdirSync再写文件，包里很多条目的名字带目录层级，父目录不存在会直接抛错，而抛错发生在一堆文件中间时，前面的文件已经写出去了，产物会处于半成品状态，重跑前记得清目录。二是没有命中处理表的扩展名必须原样写出，图片、音频、字体都在这一类，如果顺手跳过，页面就是一片空白，排查半天还以为是还原器的问题。

第四步收尾通常在入口函数的末尾，用 app-config.json 里的页面列表补齐那些包里没有实体文件的目录，顺便把分包的根路径拼进输出目录。这一步不做也不会报错，只是目录结构看着散，后面按页面找文件时容易漏。

3. 跑通最小闭环：Node 环境、命令参数与产物验证

工具类项目的门槛通常不在代码，而在环境和参数。这套脚本依赖一批做语法树和样式解析的老库，跑不起来的原因十有八九是版本对不上，而不是代码有 bug。先把环境固定住，再谈解包，能省掉大量无意义的排查。

3.1 环境准备与依赖安装

Node 版本这块没有官方硬性要求，但从经验看，14 到 16 之间最稳。太新的版本上，部分 AST 相关依赖的内部 API 有过变动，容易在执行到一半时抛奇怪的错误；太老的版本又不支持脚本里用到的语法。我一般会先用node -v确认版本，不符合就切一个，别硬扛。

安装依赖就是常规流程，进目录之后装一遍，注意看有没有报 peer dependency 冲突，有的话不要用--force一把梭，先看冲突的是哪个包：

# 进入脚本所在目录，确认 Node 版本在可接受范围内 node -v # 安装依赖，观察是否有 peer dependency 冲突 npm install # 如果装完仍报找不到模块，单独补装一遍缺失项，不要删了重来 npm ls --depth=0

npm ls --depth=0这步很多人跳过，其实很有用：它会列出实际装上的顶层依赖，跟你从 package.json 里读到的一对比，就知道哪个包没装成功。装失败最常见的原因是网络或缓存，清一下缓存重装即可，但如果你是在他人机器或临时环境里跑，也可能是 npm 源配置问题，这时改用官方源再试一次。

还有一点，这个项目不是全局安装的 CLI，没有 bin 字段，所以别指望装完之后直接敲命令名调用。所有脚本都要在项目目录里用node 文件名的方式启动，路径也建议用相对路径或绝对路径写全，避免工作目录不对导致读不到包。

3.2 命令怎么敲：参数含义和常见组合

入口脚本的参数不多，但组合起来对应几种典型用法。第一次跑建议先只解包不还原，看清包里到底有什么，再决定要不要走还原流程。原因是还原器会改动输出内容，一旦某个文件在还原时报错中断，你就分不清是包的问题还是还原的问题了。

# 最常见用法：直接解包并还原，输出到与包同名的目录 node wuWxapkg.js ./__APP__.wxapkg # 只解包不还原，先看原始产物长什么样，排查阶段优先用这个 node wuWxapkg.js -d ./__APP__.wxapkg # 输出目录已存在时覆盖，适合反复调试同一份包的场景 node wuWxapkg.js -o ./__APP__.wxapkg

参数名在不同分支上可能有出入，动手前先跑一次node wuWxapkg.js -h看实际的帮助输出，比照抄网上命令靠谱。另外注意第一个位置参数是包路径，别把参数和路径的顺序写反，反了之后脚本通常会把它当成不存在的文件，报一个很笼统的读取失败，容易误导。

如果你的包目录里有多个 wxapkg（主包一个、分包若干个），不要只跑主包。分包的页面文件和样式都在各自的包里，主包解出来只会有配置和引用，页面是空的。常见做法是写个循环，把目录下所有包挨个跑一遍，输出到同一个根目录下，这样页面路径才能拼得上：

# 批量处理目录下所有 wxapkg，统一输出到 dist 目录 for f in ./packages/*.wxapkg; do echo "处理 $f" node wuWxapkg.js -o "$f" || echo "跳过 $f" done

循环里加了|| echo是为了让单个包失败不打断整批，跑完回头看哪些被跳过，再单独处理。批处理时如果多个包输出到同一目录，覆盖开关一定要带上，否则第二个包会提示目录已存在然后什么都不做，你会以为它跑成功了。

3.3 产物核对：怎么判断这次解包是成功的

命令没报错不等于解包成功。我见过太多次「跑完了、目录里有东西、打开一看全是空文件」的情况。落盘之后花两分钟做一次体检，比后面拿着残缺产物分析半天要划算。

第一步看规模和结构，文件数量和总体积跟包本身对得上，说明索引基本读对了。第二步看关键文件，app-config.json 能不能正常解析、pages 数组里的每一项在目录里有没有对应文件。第三步抽查一个页面的四件套是否齐全，wxml、wxss、js、json 缺任何一个都说明还原环节有遗漏。

// 解包后的体检脚本：检查 JSON 可解析、页面四件套是否齐全 const fs = require('fs'); const path = require('path'); const root = process.argv[2] || './dist'; let badJson = 0; const missing = []; function walk(dir) { for (const name of fs.readdirSync(dir)) { const full = path.join(dir, name); if (fs.statSync(full).isDirectory()) { walk(full); continue; } if (!name.endsWith('.json')) continue; try { JSON.parse(fs.readFileSync(full, 'utf8')); } catch (e) { badJson++; console.log('坏 JSON:', full); // 位置比错误信息更有用 } } } walk(root); // 拿配置里的页面列表去核对文件是否存在 const cfgPath = path.join(root, 'app-config.json'); if (fs.existsSync(cfgPath)) { const cfg = JSON.parse(fs.readFileSync(cfgPath, 'utf8')); for (const p of cfg.pages || []) { for (const ext of ['js', 'json', 'wxml', 'wxss']) { const f = path.join(root, `${p}.${ext}`); if (!fs.existsSync(f)) missing.push(`${p}.${ext}`); } } } console.log({ badJson, missingCount: missing.length }); console.log(missing.slice(0, 20)); // 只打印前 20 条，够定位问题就行

脚本里对坏 JSON 只打印路径不抛异常，是因为一个解析失败不该中断整轮检查，先把问题清单收集全再统一处理。页面四件套的核对只针对pages数组，分包页面在subPackages里，需要的话按同样的方式再遍历一层，把root + page拼成完整路径。缺失列表只打印前 20 条也是刻意的，产物动辄几百个文件，全打出来反而看不清主要矛盾。

体检通过之后再去读代码，效率会高很多。反过来，如果体检就不通过，先解决包的问题，别急着分析还原出来的 js，那上面的内容不可信。

4. 核心模块拆解：JS、WXML、WXSS 三套还原逻辑怎么落地

三个还原器的思路完全不同，这也是这个项目最值得读的地方。JS 走的是执行期拦截，WXML 和 WXSS 走的是文本层处理，配置类文件几乎是原样透传。理解了这个分工，你就知道哪类问题该去哪个文件里找答案。

4.1 app-service.js 的反混淆与 AST 还原

打包后所有页面的逻辑被合并进一个 app-service.js，模块之间用一套自定义的注册机制串起来：每个模块调一次注册函数，第一个参数是模块路径，第二个参数是工厂函数，函数体里才是真正的业务代码。所以还原的关键不是「解压」，而是「让这段代码跑起来，把每个工厂函数截下来」。

常见做法是造一个假宿主环境，把注册函数和依赖函数替换成自己的收集器，然后用 Node 的 vm 模块在沙箱里执行整段代码。执行过程中业务逻辑其实一行都没真正跑，注册函数只是把工厂函数存进一个对象，跑完后手里就有了「路径 → 函数」的完整映射。

const fs = require('fs'); const vm = require('vm'); const esprima = require('esprima'); const escodegen = require('escodegen'); const modules = {}; // 路径 -> 工厂函数 // 假宿主：define 负责收集，require 返回空壳避免执行期报错 const sandbox = { define(p, factory) { modules[p] = factory; }, require() { return {}; }, window: { __wxConfig: {} }, console, setTimeout, clearTimeout, }; vm.createContext(sandbox); vm.runInContext(fs.readFileSync('./dist/app-service.js', 'utf8'), sandbox); // 把工厂函数重新生成可读代码，路径一般能直接映射回页面文件 for (const [p, factory] of Object.entries(modules)) { const ast = esprima.parse('(' + factory.toString() + ')'); const code = escodegen.generate(ast, { format: { indent: { style: ' ' } } }); console.log(p, code.length); }

这里有几个参数值得说明。vm.createContext创建的是隔离上下文，沙箱里拿不到 Node 的全局对象，能有效避免打包代码里的环境探测逻辑走到奇怪分支。require返回空对象而不是抛错，是因为打包代码在模块顶层就可能调用依赖，抛错会让整个执行中断，收集不全。esprima.parse外面套一层括号，是因为工厂函数转成字符串后是函数表达式，直接解析会报语法错误。

要清楚这套流程的边界。它能还给你的，是模块被拆开、缩进恢复正常、语句一行一行摆好；它给不回来的是被压缩掉的变量名和全部注释。所以还原出来的代码里到处是单字母变量，别指望能直接读懂，正确姿势是先按页面路径定位到目标模块，再从字符串常量、接口地址、页面跳转路径这些「有语义的锚点」反推逻辑。这也是为什么第 3 章要先核对 app-config.json——页面路径和模块路径的对应关系，是后面所有定位工作的基础。

另外，工厂函数转字符串再解析这一步对代码格式很敏感。如果打包时用了某些语法转换，函数体里出现解构赋值或可选链，老版本的解析器可能直接抛错。遇到解析失败的模块，先把它单独拎出来看是哪一行不兼容，升级解析器或者临时跳过这个模块继续，别让一个模块卡住整轮。

4.2 WXML 与 WXSS 的文本层还原

WXML 这一层没有执行期可以拦截，能做的全在文本上。打包后的 wxml 通常被压成极长的一行，属性之间的空格被折叠，部分引号被省略，自闭合标签的写法也可能和手写时不一样。还原器的任务就是把这些重新排开，让文件重新变成人能读的样子。

// WXML 还原的核心：按标签边界断行，再统一属性书写格式 function tidyWxml(src) { return src .replace(/>\s*</g, '>\n<') // 在标签交界处插入换行 .replace(/\s{2,}/g, ' ') // 折叠多余空白 .replace(/(<\/?[\w-]+)([^>]*?)\/?>/g, (m, tag, attrs) => { const a = attrs.trim(); if (!a) return `${tag}>`; // 把没有引号的属性值补上双引号，方便后续按属性名检索 const fixed = a.replace(/=([^"'\s>]+)/g, '="$1"'); return `${tag} ${fixed}>`; }); }

正则处理文本有个绕不过去的坑：属性值里如果出现>或者引号，简单按字符切会把标签切坏。所以这段代码先做断行再做属性修补，顺序不能反，反了之后属性里的特殊字符会让后面的替换错位。修完仍然建议抽几个复杂页面人工看一眼，特别是带三元表达式插值的属性，那类内容最容易在替换中被改坏。

WXSS 的思路类似但更结构化一些。样式被打包后常常是一条规则压成一行，选择器之间没有空行，值里的空格被删掉。还原时按{和}切规则块，再按;切声明，最后统一缩进。这一步用现成的 CSS 解析库比自己写正则稳，毕竟样式里嵌套注释、媒体查询、伪类选择器这些情况，正则很难覆盖全。

两个还原器都只处理文本形态，不校验语义。也就是说，即使标签配平错了、样式规则拆错了，它们也会安静地把结果写出去，不报任何错。所以格式检查要自己补：抽几个页面看标签是否闭合、看样式块数量是否和页面对得上，这类粗检能捞回大部分问题。

4.3 配置对齐：app-config.json 决定文件落点

前面两个还原器负责「内容长什么样」，配置解析负责「文件放在哪」。app-config.json 里的pages是主包页面列表，subPackages里每个元素带一个root和一组页面路径，最终的文件路径是root + '/' + page。这个拼接规则如果不遵守，分包页面会被丢到主包目录下，后面按路径找文件时全都对不上。

const path = require('path'); const fs = require('fs'); // 把主包和分包页面统一展开成完整路径列表 function collectPages(cfg) { const main = (cfg.pages || []).slice(); const subs = (cfg.subPackages || []).flatMap(s => (s.pages || []).map(p => `${s.root}/${p}`) ); return main.concat(subs); } // 按页面路径预建目录，还原器写文件时就不用反复判断父目录 function prepareDirs(rootDir, pages) { for (const p of pages) { fs.mkdirSync(path.join(rootDir, path.dirname(p)), { recursive: true }); } }

flatMap在这里比map加flat更直白，分包数组展开后就是一层完整的页面列表。recursive: true让重复创建已存在的目录不报错，省掉了先判断再创建的分支。预建目录这一步看着可有可无，实际情况是包里有些页面只有配置没有实体文件，提前建好能保证目录结构和配置一致，读代码时不会误以为页面丢了。

配置里还有usingComponents，指向自定义组件。这些组件如果被打进了主包，会以独立文件形式出现；如果是插件形式引入的，包里根本没有实体。所以组件目录不要硬性校验存在性，只做记录就好，缺了属于正常情况。把这一层的判断做对，能少掉一多半「明明解包成功为什么文件不全」的困惑。

5. 避坑与排查：分包、插件、转译代码里最常翻车的五件事

这套脚本的代码量不大，但失败方式很杂，因为它的输入来自别人的构建产物。同一个命令，在不同来源的包上表现可能完全不一样。下面这五条是我踩过之后记下来的，按现象、原因、解决的顺序写，遇到问题时对着现象找，比从头读代码快。

5.1 解包阶段：入口、空文件与目录错位

现象一：执行入口脚本直接报读取越界，或者解出来的文件全是 0 字节。

原因通常是包本身不完整，或者头部字段被改过。wxapkg 的开头和结尾各有一个固定标记字节，脚本读到不匹配的值时，后续的长度字段就全乱了，索引区偏移错位，最后切出来的文件自然是空的。也有一种情况是拿到的根本不是主包，体积对不上，头部结构是另一种布局。

解决方式是先做最基础的判断：看文件大小，看首字节是不是那个固定标记，和手上另一份已知能用的包对比一下头部十几个字节。如果标记不对，别改代码硬解，先确认拿到的文件是不是完整下载的、是不是被别的工具处理过。这一步花两分钟，能省掉后面两小时的无效调试。

现象二：包解开了，但目录结构散乱，分包页面全部落在主包目录下。

原因是只跑了主包，或者分包包的root前缀没有参与路径拼接。分包在物理上是独立的 wxapkg，主包里只有配置和引用，页面文件的实体在分包包里。批处理时如果每个包都输出到不同目录，也会出现结构对不上的情况。

解决办法是把目录下所有 wxapkg 列出来，逐个解，输出到同一个根目录，并且确认配置解析那一层把root拼进了路径。跑完之后用第 3 章的体检脚本核对一遍，缺失列表会直接把问题暴露出来。批处理脚本务必带覆盖开关，否则第二个包会因为目录已存在而静默跳过，这个坑我踩过一次，看着日志全绿，产物少了一半。

现象三：安装依赖阶段报错，或者运行时报找不到模块。

原因一般是 Node 版本和依赖不匹配。这批依赖里有几个是做语法解析的老库，在新版本 Node 上偶发内部 API 变动导致的异常；反过来，Node 版本太老又不支持脚本里的一些写法。还有一种情况是安装过程被网络打断，node_modules 处于不完整状态，但 npm 没报错。

解决办法是先锁定一个能跑的版本区间，再清理重装。重装前用npm ls --depth=0看实际装了什么，缺哪个补哪个，不要上来就删整个目录重来，那会把已经装好的部分也丢掉。如果只是运行时单个模块报错，也可以先把它单独装上验证，确认是版本问题还是代码问题，再决定要不要换环境。

5.2 还原阶段：变量名、标签配平与组件缺失

现象四：js 还原出来了，但全是 a、b、c 这种单字母变量，完全读不下去。

这不是还原失败，而是压缩混淆的必然结果。还原器做的是拆模块、恢复缩进和换行，它没有能力把被压掉的语义名字猜回来。指望它输出接近源码的东西，是不现实的。

正确的用法是把它当索引用：先按页面路径找到对应模块，再从里面找有语义的锚点，接口地址、跳转路径、固定文案、配置项的 key，这些字符串在压缩时不会被改。顺着锚点反推调用关系，比逐行读变量定义有效得多。真需要精确对照的话，最终还是要拿产物跟手上的源码做 diff，而不是靠读还原结果去重构。

现象五：页面 wxml 里出现大量自定义组件标签，但目录里找不到对应文件。

原因是组件以插件形式引入，或者被编译进了主逻辑包里，物理上不存在独立的 wxml。这类情况在配置的usingComponents里能看到引用，但包里没有实体，属于正常现象，不是解包出了问题。

处理方式是把组件目录的校验降级为记录，不要当成错误。真正需要关注的，是那些「配置里有引用、包里也有同名文件但内容为空」的条目，那才说明切片或还原环节出了问题。区分这两者的办法很简单：看文件是否存在。不存在就是插件或内置，存在但为空才是异常。

把上面五条串起来看，会发现一个规律：解包阶段的问题几乎都能通过检查输入文件解决，还原阶段的问题几乎都要靠调整预期解决。分清楚问题出在哪一侧，排查方向就不会跑偏。

提示：这套流程只适用于自己开发或已获授权的小程序产物，用于学习打包机制、排查自己项目的线上问题。别人的包不要碰，这是底线，不是建议。

6. 二次开发：把一次性解包改成可持续对账的小工具

单次解包的价值有限，真正省时间的是把它变成能反复跑、能对比的工具。我在项目里做过几次改造，方向不复杂，都是围绕「让产物可检索、可比较」展开的。

第一个改造是加一份结构化索引。解包完成后扫一遍输出目录，把页面路径、文件大小、是否存在四件套整理成一个 json 或者 markdown 表。这样下次再拿到新包，不用重新翻目录，直接看索引就能定位到关心的页面。实现上就是在体检脚本基础上多写几十行，把结果序列化出去，成本很低。

第二个改造是加对比能力。同一份代码两次上传后的产物，用目录 diff 一跑，改动范围一目了然，比自己回忆改了哪些文件靠谱。实际做的时候要注意先排除时间戳、构建哈希这类每次都变的字段，否则 diff 结果全是噪音。我一般会写个小脚本先做归一化，把明显的易变字段抹掉，再跑目录比对。

第三个改造是把它接进 npm scripts，让团队成员不用记命令。改完之后，解包、体检、对比各是一条命令，参数走环境变量或默认值，新人上手不用再问「那个脚本叫啥来着」。

{ "scripts": { "unpack": "node wuWxapkg.js -o ./dist/__APP__.wxapkg", "check": "node tools/check.js ./dist", "report": "node tools/report.js ./dist ./out/index.md", "diff": "node tools/diff.js ./dist/old ./dist/new" } }

这套改造里，check是必须的，report和diff看团队习惯。参数统一走脚本内部的默认值，命令行只传目录，能大幅降低误用概率。另外dist目录建议加进版本控制的忽略列表，产物每次都不一样，提交进去只会制造无意义的变更记录。

有一个教训值得说：我一开始图省事，把解包和对比写在一个脚本里，跑一次就把旧目录覆盖掉，结果想回溯上一次的产物时发现已经没了。从那以后我每次跑解包都强制把输出写到带时间戳的目录，对比脚本只读不写，旧产物保留最近三次。多占一点磁盘，换回来的是随时能对照的后悔药，很值。

如果你也打算在这套脚本上做自己的工具链，建议先别急着改还原器，那部分逻辑最复杂也最容易改坏。从入口和收尾环节入手，加索引、加校验、加批处理，收益明确且风险可控，等把产物结构摸熟了再动核心模块也不迟。希望帮到你。

本文还有配套的精品资源，点击获取