做前端的人大概都遇到过这种场面交付给客户的是一个纯前端跑的小工具或者一个 H5 小游戏代码打包压缩完往服务器一放懂行的人按 F12 就能把逻辑看个七七八八改个变量名、换个皮肤就成他自己的了。这时候就会有人翻出JJencode这类工具把 JS 代码糊成一坨$、_、!、[、]的符号汤扔给想抄的人自己头疼去。JJencode 加密解密工具这个概念说白了就是围绕这套符号化编码来回折腾的工具集——编码端把可读的 JavaScript 变成人类几乎无法阅读的符号表达式解码端再把它还原回来做调试、审计或者二次维护。它解决的问题不是绝对保密而是抬高阅读门槛让顺手抄的人从复制粘贴五分钟变成啃半天还不一定啃得动。这篇文章适合三类人看一是手里有前端代码需要做基础防护的开发者二是接手了别人混淆代码、被逼着还原逻辑的维护者三是对代码混淆原理好奇、想自己动手写一套编码器的技术爱好者。下面我把这套东西从原理到实操、从工具选型到踩坑经验一次性讲透。1. 先搞清楚 JJencode 到底在干什么1.1 从一次源码裸奔说起为什么前端代码总想藏一藏前端的代码保护有个天然的困境无论你怎么处理最终交付到用户浏览器里的东西一定是可执行的 JavaScript而可执行就意味着可阅读。服务端代码可以藏进机房前端代码没法藏。所以这个领域里所有方案的出发点都是一致的——不追求不可破解只追求破解成本高于收益。说得再直白些你防不住真正的高手但你可以让 90% 的顺手党在打开控制台三十秒后选择放弃。JJencode就是在这个定位上出生的。它不生成密钥不做非对称加密也不依赖任何运行时秘密它做的事情只有一件把每一个字符都替换成一串由符号组成的表达式让源码在视觉上彻底失去语义。这种方案的防护强度常被高估但它的成本极低——一个文件、一条命令几秒钟就能完成对小型项目来说性价比很高。我在实际项目里见过两种极端。一种是完全不做处理源码直接上线连压缩都没做变量名还是getUserInfo这种另一种是把混淆当成了银弹觉得混淆完就万事大吉结果核心算法照样被人扒出来。这两种都不对。正确的认知是混淆属于门锁级别的防护能挡君子不挡小人它真正的作用是筛选攻击者——把随手一抄的人筛掉剩下的那部分人本来也不是你一个前端混淆能挡住的。所以在你决定用不用 JJencode 之前先问自己一个问题我要保护的是商业逻辑不被复制还是代码不被直接扒走前者需要把核心逻辑搬到服务端后者才是混淆工具的战场。搞清楚这一点后面的技术选择才不会走偏。1.2 名字叫加密本质是换了一套字符表这里必须先纠正一个特别常见的误解。JJencode 的很多介绍都把它叫成加密工具但严格来说它做的事情是编码encoding不是加密encryption。两者的分界线非常清晰加密必须有密钥没有密钥就无法还原而编码只是换一种表示形式规则是公开的、确定的、可逆的任何人拿到编码结果和规则都能还原。打开一个经过 JJencode 处理过的文件你看到的大概是这样一幅景象满屏的$、_、~、、!、[、]、{、}、(、)、.、,中间夹杂着$__、$$_$、$_$$这类由美元符号和下划线组成的变量名。看起来密不透风其实它的还原路径是完全确定的——只要你能让它跑起来它自己就会把原始代码还原出来然后执行。这就引出了一个非常关键的实操结论浏览器本身就是最好的解码器。你不需要逆向那堆符号你只需要在它把原始代码拼装完成、准备执行的那一刻把那段字符串截下来。这个思路是后面所有解密操作的核心记住它能省你几个小时。1.3 和 JSFuck、UglifyJS、Base64 手势的区别在哪市面上的 JS 保护/精简方案有一堆很多人搞不清它们的定位差异。我整理了一张表按是否可逆、运行开销、防护强度、适用场景四个维度对比这张表建议先存下来选型的时候能直接用。方案原理是否可逆体积膨胀运行开销防护强度适用场景JJencode字符映射为符号表达式完全可逆约 5~10 倍有明显开销低-中小型脚本、需要快速上手的场景JSFuck仅用 6 个字符重写一切完全可逆约 50~100 倍开销很大低技术演示、极客玩法UglifyJS/Terser压缩 变量重命名不可还原原名反而减小几乎为零极低生产环境必做的基础项Base64 eval编码后动态执行完全可逆约 1.3 倍很小极低只求别一眼看到字符串数组 索引常量提取 索引化需专门处理约 1.5~3 倍小中商业项目常用方案WebAssembly编译为字节码反编译成本高视模块而定小中-高计算密集型核心逻辑从表里能看出一个很关键的事实膨胀倍数和防护强度并不是正相关的。JSFuck 能把代码膨胀上百倍防护强度却和 JJencode 一个级别因为它俩的还原思路是一样的——都是让代码自己把原始内容吐出来。而真正防护强度更高的方案比如常量提取加控制流平坦化膨胀倍数反而更可控。我个人的选型顺序一直是先 Terser 压缩必须做再决定要不要上字符串数组混淆商业项目推荐如果还有余力再考虑关键逻辑上服务端或者 WebAssembly。JJencode 在这个序列里的位置比较尴尬——它比压缩强但比字符串数组混淆笨重更多时候我把它当成一个演示工具或者极简场景下的快手段来用。2. 编码机制拆解那一堆符号到底在拼什么2.1 借内置对象的类型转换反推出需要的字符要看懂JJencode得先接受一个 JS 里的小把戏任何值强制转成字符串都会得到一个固定的结果。这几个表达式是所有符号化编码工具的字母表源头![] // false !![] // true [] [] // [][[]] // undefined ({} ) // [object Object] (1/0) // Infinity (1e3) // 1000 ({}) // NaN有了这些你就能凑出一个字符池。比如从false里能取到f、a、l、s、e从true里能取到t、r、u从[object Object]里能取到o、b、j、c、t、O、 、[、]从Infinity里能取到I、n、f、i、y从undefined里能取到u、n、d、e、f、i。把这些字符串按顺序存进一个数组再配上索引任何字符都能用数组下标的形式取出来。这就是整个编码体系的基石。举个最简化的例子如果我想得到字符o它出现在[object Object]的第 1 位那么({})[1]就等价于o。真实实现里的索引会更绕因为它还要把1这种数字本身也变成符号但思路是一样的。注意上面这些表达式返回的具体字符串内容和引擎实现有关虽然现代浏览器表现一致但如果你在做跨端兼容或者需要极致稳定建议拿实际环境跑一遍确认而不是照抄教程。2.2 变量名本身就是一张查找表光有字符还不够还需要数字和操作。JJencode 的巧妙之处在于它用一套以$和_为核心的变量命名体系把索引计数器和字符表塞进了变量名里。你会看到类似$___、$__$、$_$_、$$$$、$$_$这样的名字它们各自承担不同职责有一部分是递增计数器形如$用来在拼装过程中维护一个游标有一部分是字符表容器比如$$$$里存着一长串用拼接出来的各类内置对象字符串剩下的都是中间变量每次取字符都是(表)[下标]的形式结果直接参与字符串拼接。这套设计的直接后果是你没法通过搜索变量名来定位逻辑。因为所有变量都是$和下划线的排列组合长得几乎一样IDE 的重命名和查找引用功能在这种文件上基本失效。这正是它提升阅读成本的来源也是它让人头疼的地方。但反过来看这也给了还原方一个明确的突破口只要盯住最后的那个执行调用前面所有的拼装都只是中间过程。前面折腾一百行最后无非是把结果传给了eval或者Function构造器。2.3 执行入口就是还原的钥匙几乎所有这类编码器的收尾结构都长一个样把前面拼出来的字符串作为参数传给一个可以执行字符串的函数。简化示意如下以下为原理示意不是原始实现// 前面几百行都在拼一个字符串 s // 最后一步 $.$_($.$_ /* 拼装出来的源码字符串 */);真实代码里可能写成$.$_($.$_)也可能嵌套几层但咽喉位置只有一个。你要做的不是读懂那几百行而是在那几百行执行完之后、字符串还没被当成代码跑起来之前把它抓住。抓的方法有三种从易到难排列改代码法把最后那个执行语句整体替换成console.log(...)直接打印。断点法在浏览器调试器里给eval或者Function.prototype.constructor下断点运行时自然停在传入参数的位置。重写执行器法在自己的环境里把全局eval换成自定义函数先记录再执行。这三种方法在后面的实操章节里会展开讲这里先建立一个认知所谓解密 JJencode本质上是劫持它的执行流程而不是逆向它的算法。认知对齐了操作就简单了。3. 手把手实操编码、验证、还原的完整链路3.1 环境与工具准备先说工具获取。JJencode 的实现在圈子里流传好几个版本比较省事的路子有两条路线一直接用社区里的同名 npm 包。如果包管理器里搜得到装下来就能用抛出一个字符串、返回编码结果的 API 形态通常很朴素npm install jjencode --save-devconst jjencode require(jjencode); const source function hello(){ console.log(hi); }; const encoded jjencode(source, ); console.log(encoded.length); // 观察膨胀比例路线二自己养一份源码。把编码函数那几百行存成jjencode.js用module.exports导出。好处是完全可控不会被外部依赖的版本变化影响坏处是要自己维护。我一般选这条因为混淆工具这种东西一旦进了构建链你就不希望它的行为在某个 patch 版本里悄悄变掉。环境上没什么特别要求Node 14 以上、任意现代浏览器都够用。真正需要注意的是编码前后的一致性校验这个后面单独讲。3.2 编码这一步的几个关键选择编码本身一条命令的事但有几个参数和策略上的选择会直接影响后续体验值得单独说。第一编码粒度选文件级还是函数级。整个 bundle 一把梭编码好处是省事坏处是任何一个字符出问题都会导致整包挂掉而且膨胀后的体积会非常夸张。我一般只对关键函数做编码比如授权校验、加密解密的核心逻辑其余部分走常规压缩。这样既控制了体积又保证了关键位置有保护。第二编码前必须先压缩。顺序别搞反。先用 Terser 做变量重命名和死代码消除再上 JJencode。原因很实在压缩后的代码更短编码后的膨胀绝对值也更小而且压缩会顺手去掉注释和空白避免把注释里的敏感信息一起编码进去——这点很多人不在意但注释里写着这里是临时方案密码写死为 xxx然后一起打包上线的事我见过不止一次。第三字符集不要自己瞎改。JJencode 用的符号集是精心设计过的改动后容易出现解析歧义。这条属于别自作聪明类型的建议看着不起眼踩一次坑能让你查一整天。一个典型的两步流程大概是这样# 第一步压缩 npx terser src/core.js -c -m -o dist/core.min.js # 第二步编码 node scripts/encode.js dist/core.min.js dist/core.encoded.jsencode.js里做的事情就是把读文件、调编码函数、写文件三步串起来再加一点日志输出方便在 CI 里看结果。3.3 编码结果怎么验证才算过关编码完直接扔进项目里跑是我见过最常见的错误做法。因为编码出错的表现往往不是报错而是什么都不发生——函数被调用了但返回值是undefined或者逻辑走到了错误的分支。这种问题排查起来极其痛苦你面对的是一堆符号连断点都不知道往哪打。我固定用一套三层验证法第一层体积检查。记录编码前后的字节数算一下膨胀比例。正常情况下这个比例落在一个相对稳定的区间内如果你发现某次编码后体积只涨了 1.2 倍八成是编码函数提前返回了原字符串压根没生效。第二层语法检查。把编码产物直接交给 Node 做一次语法解析不执行只验证能不能被正确解析const fs require(fs); const acorn require(acorn); const code fs.readFileSync(dist/core.encoded.js, utf8); try { acorn.parse(code, { ecmaVersion: 2022 }); console.log(语法检查通过); } catch (e) { console.error(语法异常:, e.message); }这一步能拦下大部分编码过程中的低级错误。第三层行为验证。用一组固定输入跑编码前后的函数比对输出是否完全一致。这一步最关键因为它验证的是语义没被改变。我通常维护一个小型的用例集十几条输入输出对就够每次编码后自动跑一遍。const original require(./dist/core.min.js); const encoded require(./dist/core.encoded.js); const cases [ { input: abc, expect: abc }, { input: , expect: }, { input: 中文测试, expect: 中文测试 } ]; cases.forEach(({ input, expect }) { const a original.transform(input); const b encoded.transform(input); if (a ! b || b ! expect) { throw new Error(不一致: ${input} ${a} / ${b}); } });提示编码后的模块在require时可能因为执行时机、严格模式等问题行为和原来不同用例里一定要覆盖空值、中文、超长字符串这几类边界光测正常路径是不够的。3.4 还原解密的三条实操路径到重头戏了。假设你手上有一个别人给的、经过 JJencode 处理的文件要把它还原成可读代码。前面说过核心思路是劫持执行流程下面给出三种具体做法从最快到最稳排列。路径一改最后一行直接打印。定位文件末尾那个形如$.$_($.$_...)或者eval(...)的调用把整句替换成打印语句。改完之后在 Node 里跑一遍原始代码就出现在终端里了。// 改之前 $.$_($.$_ /* ... 一长串拼装 ... */); // 改之后 console.log($.$_ /* ... 一长串拼装 ... */);这个方法成功率最高因为它绕开了所有执行环境的差异纯粹做字符串拼装。唯一的要求是你得找准那一句——通常在文件的最末尾而且里面会有一个明显的执行器标识。路径二调试器下断点。打开浏览器把编码文件引入页面在 Sources 面板给eval打断点或者对Function构造器打刷新页面代码会停住此时看调用栈里的参数就是原始源码。这个方法的优势是不需要改动文件对线上环境或压缩过的文件同样有效适合做线上问题排查。路径三包装执行环境。在自己写的 Node 脚本里把全局的eval和Function换掉先记录再决定要不要真的执行const fs require(fs); const vm require(vm); const code fs.readFileSync(target.encoded.js, utf8); let captured null; const sandbox { console, eval: (s) { captured s; return s; }, Function: function (...args) { const body args[args.length - 1]; captured body; return function () {}; } }; vm.createContext(sandbox); try { vm.runInContext(code, sandbox); } catch (e) { // 执行阶段的错误可以忽略我们只要捕获到的字符串 } console.log(captured);第三条路最工程化因为你把整个流程脚本化了可以批量处理、可以接进流水线。代价是要处理沙箱环境里各种全局对象缺失的问题有时候得手动往sandbox里补window、document之类的占位对象。注意还原他人代码前请确认你有相应的授权这套技术用于自己项目的调试、审计、迁移是合理的用于其他目的就超出技术范畴了。3.5 把编码接进构建流水线手工编码一次两次还行长期维护一定要进流水线否则迟早出现某次发版忘了编码源码裸奔上线的事故。我的做法是在构建脚本里加一个独立步骤并且加上防漏检查。// scripts/build.js const fs require(fs); const path require(path); const jjencode require(./vendor/jjencode); const { minify } require(terser); async function build() { const raw fs.readFileSync(src/core.js, utf8); // 1. 压缩 const minified await minify(raw, { compress: { drop_console: true, drop_debugger: true }, mangle: { toplevel: true } }); // 2. 编码 const encoded jjencode(minified.code, ); // 3. 膨胀比例守卫 const ratio encoded.length / minified.code.length; if (ratio 1.5) { throw new Error(编码可能未生效膨胀比例仅 ${ratio.toFixed(2)}); } // 4. 输出 const out path.join(dist, core.encoded.js); fs.mkdirSync(dist, { recursive: true }); fs.writeFileSync(out, export default ${encoded};, utf8); console.log(构建完成: ${out}膨胀 ${ratio.toFixed(2)} 倍); } build();这里加的那个膨胀比例守卫是我踩坑之后加的。有一次依赖升级后编码函数的行为变了静默返回了原字符串构建一路绿灯直到上线后有人截图给我看源码才发现压根没编。加了这个断言之后同类问题在构建阶段就会被拦下来。4. 保护强度实测它能挡住谁挡不住谁4.1 对抗成本的真实评估我很反感把混淆工具吹成代码保险箱的说法所以这块我按实际对抗场景拆开讲不绕弯子。能挡住的打开控制台随手看看的人想复制粘贴改改就用的同行初级爬虫和自动化扫描脚本很多工具对符号密集的文件会直接解析失败。这部分人能占到 80% 以上也是绝大多数项目真正需要防的对象。挡不住的有前端逆向经验的人。前面讲的三种还原方法一个熟练工从拿到文件到还原出源码快的话十几分钟慢的话一两个小时。这个时间成本在真正的商业竞争面前基本等于零。成本对比很说明问题你自己上一套 JJencode从查资料到接进流水线大概半天到一天。别人还原你的代码熟练的话一到两小时。这个投入产出比是不对等的——但换个角度想如果你的代码价值连别人花一小时还原都不值得那其实也不需要保护如果价值远高于这个数那 JJencode 又明显不够。所以我的结论一直是JJencode 适合当第一道门槛不适合当最后一道防线。它的正确位置是和其他手段组合使用而不是单打独斗。4.2 别人会怎么破你常见还原手法清单知己知彼我把常见的还原套路列一下你在设计保护方案时可以对照着看哪些能防住、哪些防不住。还原手法技术门槛耗时经验值JJencode 是否有效备注直接搜索关键字极低几秒有效符号化后关键字消失格式化 手工阅读低半小时以上部分有效可读性极差但结构仍在改最后一行打印低十几分钟无效最常用的破解方式调试器断点抓 eval低十分钟无效不改文件也能做沙箱劫持执行器中半小时无效可脚本化批量处理AST 静态分析中高数小时部分有效需要专门写解析规则符号执行求解高不确定有效成本远超收益基本不会有人做这张表透露的信息量很大。前三行加起来就覆盖了绝大多数实际场景而 JJencode 对其中两种几乎毫无抵抗力。原因还是前面说的它把代码藏起来了但没把代码锁起来只要能让它跑它自己就会把答案交出来。真正有效的防护思路是让代码跑起来也不给你——比如把核心逻辑放到服务端前端只负责发请求或者用 WebAssembly 承载关键算法让还原者面对的是字节码而不是源码。这些方案的共同点是执行环境不在攻击者完全掌控之下。而纯前端的任何保护执行环境都在用户手里理论上就不存在绝对安全。4.3 组合策略把防护做在刀刃上基于上面的分析我给一套我认为性价比最高的组合方案按投入从小到大排列你可以按项目实际情况取用。第一层必做项。Terser 压缩 变量重命名 移除 console 和 debugger。这一步成本几乎为零收益很直接且不影响性能。任何上生产的项目都该做。第二层推荐项。关键字符串常量化把敏感信息接口路径、校验用的魔法值、错误提示提取到一个字符串数组里用索引访问。这一步能挡住大部分基于关键字搜索的抄袭成本也就加上一两百行构建代码。第三层按需项。对核心函数上 JJencode 或者更轻量的编码方案。注意是核心函数不是整个项目。体积膨胀和运行开销的代价只让少数代码承担整体体验不受影响。第四层关键项。把真正不能泄露的东西挪到服务端。授权校验、核心算法、价格计算这些逻辑一旦放到前端什么混淆都是心理安慰。我见过太多项目在这上面栽跟头——前端做了三层混淆结果接口返回的 JSON 里直接带着完整的价格明细。第五层合规项。别把不该塞进代码的东西塞进去。密钥、数据库连接串、内部接口地址这些不是混淆一下就行的问题而是压根不该出现在前端。混淆会让它们更难被发现但一旦被还原就是完整泄露风险反而更大。5. 常见问题与排查实录5.1 编码后代码跑不起来从四个方向排查这是最高频的问题我按出现频率从高到低排了个序。方向一编码前不是合法 JS。比如压缩阶段产出的代码用了较新的语法而编码器的解析逻辑不认。表现是编码过程直接抛错或者产出一个语法畸形的字符串。排查方式很简单把编码前的代码单独用acorn.parse走一遍过不了就是上游的问题。方向二编码结果被拼接进了错误上下文。比如你把它塞进了一个 ES Module 里但编码产物依赖window这类全局对象或者塞进了严格模式的函数体内this的指向变了。这类问题的典型表现是报错信息指向的位置根本看不懂因为错误堆栈是符号化的。排查建议是在编码产物外层包一层try/catch把错误信息和原始堆栈一起打印出来。方向三执行时机不对。编码后的代码往往是在模块加载阶段就执行的如果它依赖的 DOM 还没就绪或者依赖的另一个模块还没加载完就会失败。这个坑我踩过现象是本地开发正常打包上线就挂因为打包后模块的执行顺序变了。解法是把编码后的代码包成一个函数等到合适的时机再调。方向四字符集与编码问题。文件读写过程中如果编码参数没指定中文和特殊符号可能被破坏编码后的符号串里混进了错误字符导致整个表达式求值失败。这个后面单独说。5.2 字符编码与文件读写一个隐蔽的坑这个坑特别隐蔽因为它的表现完全不像编码问题。你编码、部署、运行控制台没有报错但某个函数返回的结果就是错的或者中文全变成了乱码。根因往往在文件读写这一环。Node 的fs.readFileSync如果不指定编码返回的是 Buffer如果指定了但和文件实际编码不匹配就会做一次错误的转换。而 JJencode 处理后的内容全是 ASCII 符号看起来不会有编码问题但它内部拼装出的原始源码字符串是包含中文的一旦这一层被破坏还原出来的代码里字符串字面量就全错了。我的固定写法是读写都显式指定utf8并且在编码完成后做一次中文回环校验——准备一条带中文的测试用例跑一遍编码再还原比对是否完全一致。这个用例现在在我的用例集里是必备项加进去之后这类问题再没出现过。const fs require(fs); // 读显式指定 const raw fs.readFileSync(src/core.js, utf8); // 写显式指定且不带 BOM fs.writeFileSync(dist/core.encoded.js, output, { encoding: utf8 });注意Windows 平台上的某些编辑器会偷偷写入 BOM 头BOM 出现在编码产物开头会导致解析异常。如果你的项目是跨平台协作构建脚本里最好加一步 BOM 检测。5.3 体积与性能代价到底有多大很多人关心编码后性能掉多少。我按自己测过的几组数据给个大致范围特别注意这些是经验值你的实际数字会因为代码结构、运行环境差异很大。指标编码前压缩后编码后变化幅度文件体积基准约 5~10 倍显著增大首次解析耗时基准明显增加视文件大小而定函数调用耗时基准基本持平编码只影响加载不影响逻辑内存占用基准略有增加主要来自字符串常量关键结论是编码影响的是加载和解析阶段不影响逻辑执行阶段。因为标记为编码的那部分代码在首次执行时就已经被解码成普通函数了后续调用走的是正常路径。所以如果你的瓶颈在运行时编码不会让它更糟但如果你的瓶颈在首屏加载编码就会雪上加霜。这也是我一直强调只对核心函数编码的原因。一个 200KB 的 bundle 整体编码后可能变成 1.5MB首屏直接多出几百毫秒而只编码其中 10KB 的核心逻辑膨胀后的绝对增量只有几十 KB用户几乎无感防护效果却一点不打折。5.4 问题速查表最后整理一张速查表出问题的时候对着查比从头想快得多。现象最可能的原因排查动作处理方式编码后体积几乎没变编码函数未生效或提前返回打印编码函数返回值长度检查版本、加膨胀断言语法解析报错语法版本不匹配用 acorn 单独解析编码前代码降级语法或升级解析器运行时无报错但结果错误中文/特殊字符被破坏做中文回环用例读写显式指定 utf8本地正常线上失败模块执行顺序变化检查打包产物的依赖顺序包成函数延迟执行报错堆栈看不懂编码产物缺少 sourcemap检查是否生成映射文件单独维护映射不随产物发布首屏明显变慢编码范围过大对比编码前后产物体积缩小到核心函数调试时无法打断点符号化后行号无意义定位到解码后的执行点在 eval/Function 处下断点表里sourcemap那一行值得多说两句。做混淆的人经常忘了一件事sourcemap 是完整还原源码的钥匙你要是把它一起发布到线上前面所有混淆工作就全白做了。我的做法是映射文件单独生成、单独存储只在内部调试环境用构建脚本里加一条硬性检查产物目录里出现.map文件就直接让构建失败。6. 一点个人经验这套东西的正确用法用了几年这类工具我最大的感受是别把它当成安全措施把它当成工程手段。前者会让你产生虚假的安全感后者才能让你做出合理的取舍。具体到操作层面有几条是我反复验证过的。第一永远先压缩再编码顺序反了体积会膨胀得离谱而且压缩可能改变代码结构导致编码结果不稳定。第二编码范围控制在 20% 以内超过这个比例首屏性能的代价就会开始明显。第三编码产物一定要有行为用例兜底我现在的项目里这个用例集是必须过 CI 的没有例外。第四别在编码产物上做调试出问题就还原回源码调调完再重新编码试图在符号堆里找 bug 是纯粹的浪费时间。还有一个小技巧分享如果你需要在开发阶段频繁修改被编码的代码可以做一个环境开关NODE_ENVdevelopment时走原始源码生产构建时才走编码版本。这样开发体验完全不受影响产出的东西又是编码过的。实现起来就是构建脚本里加一个判断几行代码的事但省下的时间很可观。至于往后还能怎么扩展我的思路是往轻量化混淆方向走——JJencode 的膨胀比太高符号集又过于张扬一眼就能认出来用的是哪套工具。如果能做一套自定义符号表的编码方案配合字符串数组和控制流拆分防护强度和体积都能做到更优的平衡点。不过那是另一个话题了等真正落地了再单独写一篇。