javascript混淆不是加密，而是通过重命名变量、打散控制流、字符串数组化等手段抬高逆向门槛；它无法阻止还原，但能促使攻击者放弃分析。
JavaScript 混淆不是加密，而是增加静态分析成本
混淆不能阻止有心人还原逻辑，但能有效抬高逆向门槛——它让 getUserInfo() 变成 _0x4a2f[0]，把嵌套的条件判断打散成无意义的布尔运算，让调试器里看到的变量名全是 a、b、_0x1234。这不是为了“防住”，而是让攻击者在「花 2 小时看懂一段登录校验」和「转头去找下一个没混淆的站点」之间选后者。
用 javascript-obfuscator 做基础混淆最实用
npm 安装后直接调用 CLI 或集成进构建流程，比手写正则替换靠谱得多，且支持多层控制。关键不是“全开”，而是按需启用：
-
renameGlobals: false—— 默认会重命名全局函数（如alert），可能破坏依赖，必须关掉 -
controlFlowFlattening: true—— 把 if/else/for 转成 switch+状态机，提升可读性损耗，但运行时有轻微性能开销（约 +5% 执行时间） -
stringArray: true—— 字符串统一存进数组再通过索引取，防止关键词被 grep 出来（比如"api/v1/login"） -
identifierNamesGenerator: "hexadecimal"—— 避免用array1、func2这类带语义的假名，选十六进制更“无信息”
const JavaScriptObfuscator = require('javascript-obfuscator');
<p>const obfuscatedCode = JavaScriptObfuscator.obfuscate(<code> function calculatePrice(base, tax) { return base * (1 + tax); } console.log(calculatePrice(100, 0.08)); </code>, {
compact: true,
controlFlowFlattening: true,
stringArray: true,
identifierNamesGenerator: 'hexadecimal',
renameGlobals: false
});</p><p>console.log(obfuscatedCode.getObfuscatedCode());混淆后必须做三件事，否则上线即翻车
混淆是破坏性操作，不验证就发版等于主动埋雷：
立即学习“Java免费学习笔记（深入）”；
- 保留一份未混淆的 source map（仅本地存档），否则线上报错堆栈无法定位到源码行
- 在真实浏览器环境跑一遍核心流程（尤其是涉及
eval、Function构造函数、webpack动态import()的地方），混淆可能让new Function('return ' + str)失效 - 检查第三方 SDK 是否有白名单要求——有些支付或埋点 SDK 会检测
window上是否存在特定函数名，混淆后名字变了就会静默失败
真正该防的不是代码，而是接口和状态
前端混淆再强，fetch('/api/user') 的请求地址、响应结构、token 放哪、鉴权怎么验，这些全在开发者工具 Network 和 Application 标签下明文可见。混淆只是把 encryptToken() 这个函数变难读，但只要它最终吐出一个字符串塞进 Authorization header，这个字符串本身依然可截获、可重放。所以重点该放在：敏感接口加二次校验、token 绑定设备指纹、关键操作服务端留痕比对——混淆只是整个防护链上最外层的一层薄纸，别把它当防弹衣用。
