简介：中国蚁剑（AntSword）2.1.9 源码压缩包面向网络安全测试人员、Web 渗透学习者及希望二次开发的开发者，提供可离线研读的完整项目代码，便于理解轻量级 Web 安全测试平台的组织方式。压缩包共 2777 个文件、约 15.51MB，以 1471 个 JavaScript 源码为核心，辅以 204 个 Markdown 文档、175 个 JSON 配置、120 个 CSS 样式以及图片、字体、证书等资源，覆盖前端界面、插件机制、构建配置与依赖说明等模块。已有 1621 人学习下载，具备一定参考热度。通过梳理目录与源码，读者可研究远程连接管理、插件扩展、跨平台适配等设计，并学习 HTTP 交互、Web 服务器通信及漏洞探测的相关实现；也可据此定制功能、编写插件或排查运行问题。其插件系统与源码可读性较突出，读者可参考现有插件结构完成二次开发，并了解界面交互与通信模块的配合方式，适合作为 Web 安全测试与源码研究的实践材料。
1. 拿到 antSword-2.1.9 源码包，先别急着敲 npm install
拆 中国蚁剑源码 这类安全工具包，最容易犯的错是上来就npm install，然后对着满屏 postinstall 报错发呆。antSword-2.1.9 给的不是一段能贴进脚本里跑的片段，而是一套完整的 Electron 桌面端工程：主进程管窗口与本地能力，渲染进程管界面，中间靠模块注册表和一层 IPC 串起来。它的价值不在于「能用」，而在于模块怎么被扫描、编码器怎么被串进请求链路、插件怎么挂进 UI —— 这三处才是二次开发和源码研究真正的下手点。
这份源码适合三类人：想搞清楚一个跨平台安全客户端内部怎么组织模块的开发者；需要按自己团队的数据格式改编码器、加插件的二开人员；以及做流量特征梳理、想从实现侧理解数据封装顺序的安全研究方向从业者。后面按「目录 → 启动 → 模块 → 编码器 → 插件打包 → 排错 → 基线」的顺序拆，每一步都落到能复现的命令和文件路径上。
2. 目录结构与 Electron 启动链路：从 package.json 到第一个窗口
2.1 先分清哪些是源码，哪些是运行产物
解压之后第一件事不是装依赖，是把目录在脑子里分两层：一层是工程文件，一层是运行时数据。很多人改了半天代码发现界面纹丝不动，八成是改到了打包产物或者用户数据目录里。
拿到的包里大致会看到这么几块，不同打包方式可能略有出入，但对应关系是稳定的：
| 路径 | 作用 | 改不改 |
|---|---|---|
package.json | 工程清单，锁 electron 版本、依赖、scripts 入口 | 只读，看清版本再动手 |
source/app.js | Electron 主进程入口，创建 BrowserWindow | 会改，调试主进程从这里下断点 |
source/core/ | 内核：模块加载、IPC 封装、公共工具 | 会改，二次开发核心区 |
source/modules/ | 功能模块目录，一个子目录一个模块 | 会改，新增模块放这里 |
source/views/ | 渲染进程的页面与前端资源 | 会改，改界面在这 |
source/static/ | 图标、样式、第三方前端库 | 少改 |
source/languages/ | 多语言词条 | 加自定义文案时改 |
antData/（运行时生成） | 用户配置、插件、缓存，落在系统 userData 目录 | 不要提交，不要手改源码目录里的同名文件夹 |
antData这块要特别说一句。它不在源码树里，是应用第一次启动后由app.getPath('userData')算出来的路径，Windows 下一般在用户目录的 AppData 下，macOS 在 Library 下。你写的插件实际是要丢进这个目录的plugins子目录，而不是源码里的source/modules/plugin。这两个地方搞混，是后面插件不加载的头号原因。
另外提醒一句，包里如果已经带了node_modules或者dist、build之类的目录，先确认是不是别人打包剩下的产物。产物里的代码是压缩过、可能还进了 asar 的，读它等于读天书。判断标准很简单：打开source/app.js，如果是有换行、有注释的正常源码，那就是对的；如果是一行几万字符，说明你打开的是产物。
2.2 主进程与渲染进程的边界在哪
Electron 工程的坑，一半出在没分清这条边界。主进程是 Node 环境，能读写文件、能起子进程、能访问系统能力；渲染进程本质是个浏览器页面，默认碰不到 Node。两边靠ipcMain和ipcRenderer通信。
在这份源码里找这条边界，最快的办法是全局搜三个词：
# 在主进程侧找 IPC 处理入口 grep -rn "ipcMain" source/core source/app.js | head -30 # 在渲染进程侧找调用方 grep -rn "ipcRenderer" source/views source/modules | head -30 # 找 preload 脚本，它决定了渲染进程能拿到哪些能力 find . -name "*preload*" -not -path "*/node_modules/*"搜完你会看到一个模式：几乎所有功能模块都是「渲染层发起调用 → 主进程侧的处理函数执行 → 回传结果」。这意味着你要加一个新能力，光写模块的index.js不够，还得看这个模块是跑在哪一侧的。跑在主进程的模块才需要注册 IPC handler；跑在渲染层的模块直接调前端接口就行。
提示：Electron 新版本默认开启
contextIsolation，渲染进程拿不到完整 Node。如果这份源码的package.json里 electron 版本比较新，而你照着老教程写require('fs')在渲染层里必然报错。先看webPreferences里nodeIntegration和contextIsolation两个值，再决定代码写在哪。
这里有个反直觉的点：不要一上来就想「我要不要改架构」。源码的架构已经定型了，你能做的是顺着它加东西，不是把它拆了重搭。我见过有人为了加个小功能去重构 IPC 封装层，最后整个界面全崩。顺着来，别逆着来。
2.3 起一个能改代码就生效的开发环境
环境这块的核心不是命令本身，是「版本对齐」。Electron 内嵌了一个特定版本的 Node，你本机的 Node 版本只影响构建脚本和 npm 装包，不影响运行时的原生模块 ABI。这两件事必须分开看。
# 1. 确认本机 Node/npm，只用于装依赖和跑构建脚本 node -v npm -v # 2. 看清这份包锁定的 electron 版本、入口脚本名 # 不要凭记忆填版本，以 package.json 为准 node -e "const p=require('./package.json');console.log(p.devDependencies&&p.devDependencies.electron, p.scripts)" # 3. 装依赖。Electron 二进制和 npm 包元数据走的是两套地址， # 只设 registry 有时仍然会卡在 postinstall 阶段 npm install --registry=https://registry.npmmirror.com # 4. 如果第 3 步卡在下载 electron 二进制，单独指定二进制镜像后重来 export ELECTRON_MIRROR=https://registry.npmmirror.com/-/binary/electron/ npm install # 5. 启动。scripts 里通常有 start 或 dev，没有就直接调 electron npm start # 或者 npx electron .几处参数得说清楚，不然出问题不知道怎么调：
--registry只改变 npm 包元数据和 tarball 的下载源，管不到 Electron 在 postinstall 阶段自己下载的那个二进制压缩包。所以要分开设。ELECTRON_MIRROR这个环境变量在 Windows 的 cmd 里写法不一样，得用set ELECTRON_MIRROR=...，PowerShell 用$env:ELECTRON_MIRROR="..."，bash/zsh 才是export。写错了不报错，只是不生效，症状是「明明设了镜像还是卡住」。
npx electron .里的那个点代表当前目录作为应用入口。如果package.json的main字段指向的是source/app.js，那在根目录执行electron .就能起；如果main指错了或者根本没有这个字段，Electron 会去找index.js，找不到就白屏或者直接退出。启动失败第一件事永远是看main字段。
启动起来之后，调试路径要提前摸清：渲染进程的 DevTools 用快捷键或者菜单打开，主进程的调试得靠--inspect参数，在package.json的启动脚本里加electron --inspect=5858 .，然后用 Chrome 的chrome://inspect连上去下断点。主进程崩了窗口直接没了，没有断点你只能靠console.log猜，效率差一个量级。
3. 模块加载机制与编码器链路：二次开发真正下手的地方
3.1 modules 目录是怎么被扫描和注册的
模块化是这套源码最值得读的部分。source/modules/下面每个子目录就是一个模块，每个模块自己有index.js和一份描述元信息的package.json。应用启动时，内核会扫一遍这个目录，读元信息，require入口文件，把实例挂到一个统一的命名空间上。
要验证这个机制，不用读完全部代码，跑一遍日志就够了。在模块加载的那段代码里临时插一行打印：
// 位置：source/core 下负责扫描 modules 目录的文件 // 常见名字是 modules.js / loader.js，用 grep 定位： // grep -rn "readdirSync" source/core const fs = require('fs'); const path = require('path'); function scanModules(baseDir) { const names = fs.readdirSync(baseDir).filter((name) => { // 过滤掉隐藏文件和没有入口的目录 const p = path.join(baseDir, name); return fs.statSync(p).isDirectory() && fs.existsSync(path.join(p, 'index.js')); }); const loaded = {}; for (const name of names) { try { // require 缓存是按路径算的，热加载时必须先清缓存 const entry = path.join(baseDir, name, 'index.js'); delete require.cache[require.resolve(entry)]; const mod = require(entry); // 约定：模块导出对象上带 init 方法，由内核注入 antSword 实例 loaded[name] = typeof mod.init === 'function' ? mod.init(global.antSword) : mod; console.log('[module] loaded', name); } catch (e) { // 单个模块挂了不能拖垮整个应用，这是必须的隔离 console.error('[module] failed', name, e.message); } } return loaded; }这段的逻辑重点在三个地方。第一，require有模块缓存，同一个路径第二次require拿到的是缓存对象，所以任何「改了代码想热加载」的方案都必须先delete require.cache[require.resolve(entry)]，否则你改一百遍跑的还是老代码。第二，init注入实例这个约定是整套模块体系的枢纽，新模块只要遵守这个签名就能拿到全局内核对象，进而拿到配置、日志、界面引用。第三，单个模块加载失败必须 try/catch 隔离，不然一个坏模块让整个应用起不来，排错时会怀疑人生。
参数上还有一点：扫描顺序决定了console.log的先后，但不要依赖这个顺序做初始化。有些模块之间有依赖（比如日志模块必须先于业务模块就绪），源码里通常会用一个显式的加载顺序数组而不是目录顺序来保证。找找core里有没有类似['antSword', 'logmanager', 'setting', ...]这样的数组，有的话就是它。
3.2 照着现成模块写一个能被自动加载的自定义模块
理解了扫描规则，加自己的模块就是填空题。先建目录：
# 在源码的 modules 目录下新建，命名用小写，避免和已有模块冲突 mkdir -p source/modules/demo然后写入口文件：
// source/modules/demo/index.js // 最小可加载模块：只做初始化挂载和一个纯函数方法，不碰界面 const Demo = { // 内核调用时传入 antSword 实例 init(antSword) { this.core = antSword; // 挂到全局命名空间，方便别的模块或调试控制台直接访问 // 控制台里 antSword.demo.echo('x') 能调通就说明挂载成功 antSword.demo = this; return this; }, // 业务方法示例：只做数据透传，便于验证调用链 echo(payload) { if (payload === undefined) { throw new TypeError('payload 不能为空'); } return { ok: true, payload, ts: Date.now() }; } }; module.exports = Demo;再补一份元信息，扫描时读的就是它：
{ "name": "demo", "version": "0.0.1", "description": "本地开发用的最小模块，验证加载链路", "entry": "index.js" }字段说明：name必须和目录名一致，不一致时某些实现会按package.json里的名字注册，导致你在控制台按目录名找不到；entry是入口文件名，如果你的内核版本不读这个字段、直接硬编码index.js，那就老老实实叫index.js，别耍花样。这是血泪经验，改名字的成本远大于收益。
验证方式很直接：重启应用，看启动日志里有没有[module] loaded demo。有，就在 DevTools 控制台执行antSword.demo.echo('hello')，返回带ts的对象说明调用链全通。没有，就往下走 3.4 的排查思路。
注意：新增模块目录必须重启应用。扫描发生在启动阶段，运行期不会自动发现新目录。改已有模块的文件内容可以靠清
require缓存热加载，改目录结构不行。
3.3 编码器接口契约：pwd、data、ext 三个参数
编码器是这份源码里最值得单独拎出来讲的一层，因为它是一个纯粹的、可单测的函数式扩展点。链路大致是这样：业务层发起一次数据交互，内核把要发送的数据塞进一个对象，交给选中的编码器加工，编码器返回改写后的对象，内核拿它直接当请求体发出去；响应回来再走解码器还原。
接口签名是固定的三参数：
// source/modules/encoder/jsonwrap/index.js // pwd: 当前配置里指定的字段名，编码器要把正文回填到这个键上 // data: 待发送的数据对象，'_' 键下是内核放入的正文 // ext: 扩展上下文，可能带配置、会话信息，具体看内核版本 module.exports = (pwd, data, ext = {}) => { if (typeof data !== 'object' || data === null) { throw new TypeError('data 必须是对象'); } // 取出内核放入的正文 const body = data['_']; // 做一个中性的 JSON 封装，演示回填逻辑 // 真实场景里这里换成你团队内部的格式约定即可 data[pwd] = JSON.stringify({ v: 1, d: body }); // 关键：原始键必须删掉，否则正文会以两种形式一起发出去 delete data['_']; // 返回值就是最终请求体，内核不再做二次加工 return data; };三个参数的含义要掰开讲。pwd是配置项里那个字段名，不同配置下可能是任意字符串，所以代码里绝对不能写死data.pass这类东西，必须用data[pwd]动态取键，否则换个配置就失效，而且失效时没有任何报错，只是数据发不出去。data里除了_之外可能还有别的旁路字段，比如标记位、分片信息，改写时不能整对象替换，只能在原对象上增删键 —— 整替换会把这些旁路字段全丢掉。
ext是最容易被忽略的。有些实现版本会在里面塞当前会话的上下文，做配置相关的编码分支时用得上。稳妥的写法是先判空再取值，不要假设它一定有内容。
解码器是配套的另一半，签名通常是(content, ext) => string，职责是把响应正文还原成业务层能直接处理的形式。编码和解码必须成对写、成对测，只测一半是耍流氓 —— 你会遇到「发出去对了，回来解析崩了」的情况，而且定位成本翻倍。
提示：
delete data['_']这一行漏掉的后果不是报错，是数据被发两遍。症状很隐蔽，表现为服务端收到的内容比预期多出一份明文。写完编码器，先看请求体 dump 再谈别的。
3.4 脱离界面做单元测试
编码器是纯函数，最好的验证方式是脱离 Electron，直接用 Node 跑。省掉的启动窗口、重新登录、手动点按钮的时间，一天下来能省一个小时起步。
// test/encoder.test.js // 直接用 node 跑：node test/encoder.test.js const assert = require('assert'); const enc = require('../source/modules/encoder/jsonwrap/index.js'); // 用例 1：正常封装，验证正文落到 pwd 指定的键上 const out = enc('k', { _: 'hello', flag: 'keep' }, {}); assert.strictEqual(out.k, JSON.stringify({ v: 1, d: 'hello' }), '正文封装格式不对'); assert.strictEqual(out.flag, 'keep', '旁路字段被误删'); assert.ok(!('_' in out), '原始键没有删干净'); // 用例 2：空正文，验证边界不抛异常 const out2 = enc('k', { _: '' }, {}); assert.strictEqual(out2.k, JSON.stringify({ v: 1, d: '' }), '空正文处理有误'); // 用例 3：入参类型错误，验证防御性检查生效 assert.throws(() => enc('k', null, {}), TypeError, '空对象没拦住'); console.log('all passed');逻辑说明：用例 1 盯的是主路径和旁路字段保值，这两个是最容易写错的；用例 2 盯边界，空字符串和undefined必须区分对待，很多编码器在空正文时会把键写成"undefined"，这是个经典翻车点；用例 3 盯防御，接口约定里写明要挡非法入参，就得有测试兜住，不然以后被人改掉都没人发现。
三个用例加起来不到三十行，但能在你改编码器格式时第一时间告诉你哪里断了。我一般会把这类测试放在test/目录下，用node test/encoder.test.js单独跑，不引入测试框架 —— 为了三个断言装一套 jest 不划算，而且这些测试不该依赖 Electron 环境。
4. 插件体系与打包：把改动变成能分发的产物
4.1 插件目录与清单文件
插件和模块是两套东西。模块在源码树里，跟着应用一起编译；插件在用户数据目录下，运行期加载，可以单独分发。这个区别决定了你的改动该放哪：只给自己用的功能改造走模块，要发给别人装的走插件。
插件的落点在antData/plugins/下，每个插件一个子目录：
# antData 是运行时目录，不在源码树里 # 先确认实际路径，不同系统不一样 node -e "console.log(process.env.APPDATA || process.env.HOME)" # 目录结构 # antData/plugins/myplugin/ # ├── package.json # ├── index.js # └── assets/清单文件里除了常规的name、version，还要有一个供宿主识别的扩展字段，常见做法是叫antSword，里面写入口和分类：
{ "name": "myplugin", "version": "0.0.1", "description": "本地调试插件", "main": "index.js", "antSword": { "entry": "index.js", "category": "tool" } }category影响的是插件在列表里归到哪一组，写错了不报错，只是找不着。名字字段和目录名保持一致这条规则在这里同样适用。
4.2 在界面里挂自己的入口
插件入口拿到的通常是内核实例或者一个注入好能力的上下文对象。具体方法名各版本可能有差异，别硬猜，先去源码里搜：
# 找插件管理器暴露的注册方法 grep -rn "register\|addPlugin\|loadPlugin" source/modules/plugin | head -20找到之后再写入口，带一层防御，避免版本不匹配时静默失败：
// antData/plugins/myplugin/index.js module.exports = (antSword) => { // 不同版本注册入口名字可能不同，先探测再调用 const manager = antSword && antSword.plugin; const register = manager && (manager.register || manager.add); if (typeof register !== 'function') { // 明确抛出，比静默 return 好排查一百倍 throw new Error('当前版本未暴露插件注册方法，检查 source/modules/plugin'); } register.call(manager, { name: 'myplugin', title: '本地调试插件', // 挂载成功后打一行日志，用于验证 onOpen() { console.log('[plugin] mounted, core version =', antSword.version); } }); };防御性判断这段不是形式主义。插件加载失败在宿主里通常只是「列表里没出现」，没有任何错误提示，你根本不知道是没扫到、扫到了但入口抛异常、还是注册方法名不对。加上显式抛出，至少能在宿主日志里看到原因。
4.3 打包配置与版本号替换
改完之后要分发，就得走打包。先看package.json的 scripts 里有没有现成的打包命令，有就直接用；没有的话，以electron-builder为例配一份：
{ "build": { "appId": "local.antsword.dev", "productName": "antSword-dev", "directories": { "output": "dist" }, "files": [ "source/**/*", "package.json", "!source/**/*.map", "!source/**/*.md" ], "asar": true, "win": { "target": ["zip"] }, "mac": { "target": ["dir"] } } }参数说明：files是白名单，只打进source下的内容和根package.json，!开头的是排除项，sourcemap 和文档打进去纯属增大体积；asar开成true会把源码压成一个归档文件，能防止随手改，代价是调试产物时要额外解包，开发阶段建议先关掉；target选zip或dir是为了快，正式分发再换安装包格式。
打包之后有个必查项：改版本号。package.json里的version不改，装到同一台机器上会被当成同一个版本，覆盖安装时用户数据可能不刷新。同时检查源码里有没有硬编码的版本字符串用于显示，两处不一致会出现「关于」页面显示旧版本的情况。
还有一个打包专有的坑：路径。开发时用相对路径读static下的资源没问题，打包进 asar 之后，__dirname的层级变了，相对路径可能指向一个不存在的位置，症状是白屏或者图标全丢。稳妥做法是用app.getAppPath()拼绝对路径，别用../数层级。
5. 避坑与排查：拆这份源码时最常翻车的五个点
5.1 依赖装到一半卡在 electron 的 postinstall
现象：npm install跑了很久，最后停在下载二进制那一步，或者超时退出，node_modules里 electron 目录是空的。
原因：npm 包元数据走 registry，但 Electron 的二进制是 postinstall 阶段由包自己的脚本从另一个地址拉的，两套源。你设了 registry 不代表二进制也走了镜像。
解决：分两步设。先设ELECTRON_MIRROR环境变量指向二进制镜像，再清掉node_modules和 lock 文件重装。Windows 下注意set和$env:的区别，写错了不报错只是不生效。实在不行就把上一次下载成功的缓存目录保留着，重装时命中的是缓存而不是网络。
5.2 改了代码，界面一点变化都没有
现象：改source/views下的文件、改source/modules下的index.js，重启应用后行为跟没改一样。
原因：三种可能，按概率排序 —— 一是改的根本不是运行的那份代码，跑的是dist里的产物或者node_modules里的副本；二是模块有require缓存，热加载没清缓存；三是改的是主进程代码，但只重启了渲染层（刷新页面），主进程还活着。
解决：先确认运行路径，在source/app.js开头打一行console.log(__dirname)，看输出是不是你改的那个目录。是，就清require.cache；主进程代码改动必须整个退出应用再起，刷新页面不管用。
5.3 新加的模块死活不加载
现象：目录建了、index.js写了、package.json也放了，启动日志里就是没有这个模块。
原因：扫描逻辑在启动时执行一次，运行期不会重新扫描；目录名和清单里的name不一致时，可能按名字注册而你在按目录名找；入口文件名不是约定的那个；或者扫描函数对目录做了白名单过滤。
解决：在扫描函数里加日志，把「扫到了哪些目录」和「哪些被过滤掉了」都打出来，一眼就能看出是没扫到还是加载失败。加载失败的会走 catch 分支，日志里一定有别的东西，别只看「没加载」三个字就下结论。
5.4 原生模块报 NODE_MODULE_VERSION 不匹配
现象：启动报错，大意是模块编译时用的 Node ABI 版本和当前运行的不一致，NODE_MODULE_VERSION后面跟两个不同的数字。
原因：npm install时用的是本机 Node，编译出的原生模块 ABI 对应本机 Node；但运行时用的是 Electron 内嵌的 Node，版本不同，ABI 就不同。这在带原生依赖的 Electron 工程里是常见病。
解决：用electron-rebuild针对当前 Electron 版本重编原生依赖，或者把打包脚本里的 rebuild 步骤固定下来，别指望npm install一次搞定。每次换 Electron 版本都要重来一遍，这是规矩，不是可选项。
5.5 编码器改了，请求体没变
现象：新写的编码器文件放进encoder目录，配置里也选了，但抓到的请求体还是老格式。
原因：四个可能 —— 编码器列表是启动时扫描并缓存的，新增目录没重启；选中的是另一个同名或相似名的编码器；编码器里漏了delete data['_']，导致新旧两份数据并存，你看到的是旧的那份；或者改了文件但require缓存没清。
解决：在编码器函数第一行打日志，打印入参和返回值，先确认它到底有没有被调用。没被调用是注册或选择问题，被调用了但结果不对是逻辑问题。这两类问题的排查方向完全相反，先分清再动手。
6. 从 2.1.9 起一条自己的开发基线：版本核对与回归清单
拿到一份源码包，最值钱的动作不是把它跑起来，而是把它变成一个可对照的基线。我一般会在解压后的第一小时做三件事。
第一件，立刻git init并打 tag。别嫌麻烦，这决定了你后面所有改动是不是可回滚：
cd antSword-2.1.9 git init git add -A git commit -m "baseline: 2.1.9 原始包，未做任何改动" git tag v2.1.9-orig这一步的意义在于：后面你改了编码器、加了模块、动了 IPC 封装，任何一次「改坏了回不去」的恐慌都不会发生。git diff v2.1.9-orig就是你全部改动的白皮书，交付或者复盘时直接拿这个说话。我见过太多人靠手动复制文件夹做备份，最后分不清哪个是哪个。
第二件，把关键文件做一次指纹记录，用于后续版本对比：
# 只对二次开发会碰到的核心文件取哈希 find source/core source/modules/encoder -name "*.js" -type f \ | sort | xargs sha1sum > .baseline.sha1 # 拿到新版本后重算一遍，直接 diff 出改动面 find source/core source/modules/encoder -name "*.js" -type f \ | sort | xargs sha1sum > .new.sha1 diff .baseline.sha1 .new.sha1 | grep '^[<>]' | wc -l这样做的价值在于，当你拿到另一个版本、想判断「要不要跟进升级」时，不用肉眼翻整个目录，先看改动面集中在哪：编码器层动得多，说明传输格式可能变了，你的自定义编码器要跟着改；core里模块加载逻辑动得多，说明插件注册接口可能不兼容；只有views和languages动，那基本是界面和文案，升级风险低。这个判断比读 release note 快得多，而且不会漏。
第三件，写一份自己的回归清单，每次改动后固定跑一遍。我的清单大概长这样：
| 检查项 | 验证方式 | 失败表现 |
|---|---|---|
| 应用能起 | npm start后窗口正常出现 | 白屏 / 进程直接退出 |
| 模块全加载 | 启动日志里逐个[module] loaded | 缺某个模块的日志 |
| 自定义模块可用 | 控制台调antSword.demo.echo('x') | 返回 undefined 或抛错 |
| 编码器主路径 | node test/encoder.test.js全绿 | 断言失败 |
| 编码器边界 | 空正文、空对象两个用例 | 抛出非预期异常 |
| 插件挂载 | 插件列表里能看到自己那条 | 列表为空 |
| 打包产物能跑 | 打完包双击运行 | 白屏 / 资源丢失 |
这七项跑完大概三分钟，但能挡住九成以上的低级翻车。清单不用长，覆盖「启动、加载、扩展点、打包」四条链路就够，关键是每次都跑，别跳项。
最后说个习惯。我早期拆这类源码包时，喜欢一边读一边改，改完直接跑，跑通了就继续改下一处。结果是有一次编码器改坏了，应用照常启动、界面照常能用，只有某类数据发出去静默失败，等我发现的时候已经在这个错误版本上叠加了十几处改动，回退成本极高，只能靠git一点点二分。从那以后我每次动扩展点之前，都强制先把.baseline.sha1和回归清单跑一遍，确认基线是干净的再开始改，改完再跑一遍。多花的三分钟，省的是三个小时。
希望帮到你。
本文还有配套的精品资源，点击获取
