做前端的人大概都遇到过这种场面：交付给客户的是一个纯前端跑的小工具，或者一个 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 保护/精简方案有一堆，很多人搞不清它们的定位差异。我整理了一张表，按"是否可逆、运行开销、防护强度、适用场景"四个维度对比，这张表建议先存下来，选型的时候能直接用。

从表里能看出一个很关键的事实：膨胀倍数和防护强度并不是正相关的。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 // 最后一步： $.$_($.$_ = /* 拼装出来的源码字符串 */);

真实代码里可能写成$.$_($.$_)，也可能嵌套几层，但咽喉位置只有一个。你要做的不是读懂那几百行，而是在那几百行执行完之后、字符串还没被当成代码跑起来之前，把它抓住。

抓的方法有三种，从易到难排列：

1. 改代码法：把最后那个执行语句整体替换成console.log(...)，直接打印。
2. 断点法：在浏览器调试器里给eval或者Function.prototype.constructor下断点，运行时自然停在传入参数的位置。
3. 重写执行器法：在自己的环境里把全局eval换成自定义函数，先记录再执行。

这三种方法在后面的实操章节里会展开讲，这里先建立一个认知：所谓"解密 JJencode"，本质上是"劫持它的执行流程"，而不是"逆向它的算法"。认知对齐了，操作就简单了。

3. 手把手实操：编码、验证、还原的完整链路

3.1 环境与工具准备

先说工具获取。JJencode 的实现在圈子里流传好几个版本，比较省事的路子有两条：

路线一：直接用社区里的同名 npm 包。如果包管理器里搜得到，装下来就能用，抛出一个字符串、返回编码结果的 API 形态通常很朴素：

npm install jjencode --save-dev

const 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.js

encode.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 对其中两种几乎毫无抵抗力。原因还是前面说的：它把代码"藏"起来了，但没把代码"锁"起来，只要能让它跑，它自己就会把答案交出来。

真正有效的防护思路是让代码"跑起来也不给你"——比如把核心逻辑放到服务端，前端只负责发请求；或者用 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 体积与性能：代价到底有多大

很多人关心编码后性能掉多少。我按自己测过的几组数据给个大致范围，特别注意这些是经验值，你的实际数字会因为代码结构、运行环境差异很大。

关键结论是：编码影响的是"加载和解析"阶段，不影响"逻辑执行"阶段。因为标记为编码的那部分代码在首次执行时就已经被解码成普通函数了，后续调用走的是正常路径。所以如果你的瓶颈在运行时，编码不会让它更糟；但如果你的瓶颈在首屏加载，编码就会雪上加霜。

这也是我一直强调"只对核心函数编码"的原因。一个 200KB 的 bundle 整体编码后可能变成 1.5MB，首屏直接多出几百毫秒；而只编码其中 10KB 的核心逻辑，膨胀后的绝对增量只有几十 KB，用户几乎无感，防护效果却一点不打折。

5.4 问题速查表

最后整理一张速查表，出问题的时候对着查，比从头想快得多。

表里"sourcemap"那一行值得多说两句。做混淆的人经常忘了一件事：sourcemap 是完整还原源码的钥匙，你要是把它一起发布到线上，前面所有混淆工作就全白做了。我的做法是映射文件单独生成、单独存储，只在内部调试环境用，构建脚本里加一条硬性检查，产物目录里出现.map文件就直接让构建失败。

6. 一点个人经验：这套东西的正确用法

用了几年这类工具，我最大的感受是别把它当成安全措施，把它当成工程手段。前者会让你产生虚假的安全感，后者才能让你做出合理的取舍。

具体到操作层面，有几条是我反复验证过的。第一，永远先压缩再编码，顺序反了体积会膨胀得离谱，而且压缩可能改变代码结构导致编码结果不稳定。第二，编码范围控制在 20% 以内，超过这个比例，首屏性能的代价就会开始明显。第三，编码产物一定要有行为用例兜底，我现在的项目里这个用例集是必须过 CI 的，没有例外。第四，别在编码产物上做调试，出问题就还原回源码调，调完再重新编码，试图在符号堆里找 bug 是纯粹的浪费时间。

还有一个小技巧分享：如果你需要在开发阶段频繁修改被编码的代码，可以做一个环境开关，NODE_ENV=development时走原始源码，生产构建时才走编码版本。这样开发体验完全不受影响，产出的东西又是编码过的。实现起来就是构建脚本里加一个判断，几行代码的事，但省下的时间很可观。

至于往后还能怎么扩展，我的思路是往"轻量化混淆"方向走——JJencode 的膨胀比太高，符号集又过于张扬，一眼就能认出来用的是哪套工具。如果能做一套自定义符号表的编码方案，配合字符串数组和控制流拆分，防护强度和体积都能做到更优的平衡点。不过那是另一个话题了，等真正落地了再单独写一篇。