最佳实践

建议

• 只混淆您自己的代码。

  不要对第三方脚本、库或 polyfill 进行 VM 混淆。它们本来就已经过压缩，混淆只会拖慢它们的运行速度。

• 使用 comment 模式进行精准保护。

  将 vmTargetFunctionsMode 设为 'comment'，然后只用 /* javascript-obfuscator:vm */ 标记敏感函数，而不是保护所有代码。请参阅针对特定函数。

• 混淆后要充分测试。

  务必在目标环境中测试混淆后的代码。有些选项会以不易察觉的方式破坏代码。运行时防御还会对测试自动化工具和调试器作出反应；请参阅测试与 CI。

• 将热点路径排除在 VM 混淆之外。

  对动画循环、实时渲染或频繁调用的代码使用 vmExcludeFunctions。它只匹配根层级的函数名（在 Async Executor 下为最外层的 async 函数）；如果要让嵌套的热点代码不进入 VM，请使用 comment 模式，只标记需要保护的函数。

重要安全提示

切勿在前端 JavaScript 代码中存放 API 密钥、机密信息或凭据，即使经过混淆也不行。

混淆会增加理解和修改代码所需的工作量，但它不是加密，也无法保证逆向工程不可能实现。在攻击者控制的环境中，运行时始终是可观察的，因此意志坚定的攻击者总能从客户端代码中提取数据。请把机密信息和具有决定性的安全判断留在服务器上。

在实践中：

• 把机密信息存放在后端服务器上
• 在服务端使用环境变量
• 通过后端代理 API 调用以隐藏密钥
• 使用由您的服务器签发的短期令牌

应该保护什么？

VM 混淆非常适合：

• 专有算法和业务逻辑
• 许可证校验代码（客户端检查）
• 防篡改和完整性校验
• 游戏逻辑和反作弊机制
• 付费功能的实现
• 价格计算逻辑

构建与发布

把混淆作为最后一个构建步骤，对编译并打包后的输出进行混淆；构建流水线请参阅运行环境兼容性。请按照选择预设中的说明，在自己的代码上测量所选预设的开销。先针对测试构建运行功能测试，然后按照测试与 CI中的说明，验证您实际发布的那个独立发布产物。