HTML5无法真正加密脚本，动态加载仅能提高逆向门槛；基础方式为createElement或import()加载，Base64混淆易被绕过，AES+Blob方案仍受限于密钥安全，核心逻辑必须置于服务端。
HTML5 本身不提供脚本加密能力，所谓“动态加载加密脚本”，实质是在传输或加载阶段对 JS 内容做混淆、加密或保护处理，再由前端解密执行。但需明确：任何前端代码都无法真正“加密”——只要浏览器能执行，就必然能被获取和还原。目标应是提高逆向门槛，而非绝对保密。
一、基础动态加载（无加密）
使用 document.createElement('script') 或 import() 动态插入脚本是最常见方式：
-
传统 script 标签注入：创建 script 元素，设置
src，插入到head或body；适合加载远程未加密 JS。 -
ES Module 动态导入：用
import('./module.js')加载模块，返回 Promise，支持按需加载；但路径必须是静态字符串或受限制的表达式，不能直接导入加密内容。
二、简单混淆 + Base64 编码（轻量级防护）
适用于对安全性要求不高、仅防快速查看的场景。原理：将原始 JS 字符串 Base64 编码后内联，运行时 atob() 解码并 eval() 或注入 script 标签。
小红书长文-谷歌浏览器
下载
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
- 服务端或构建时对 JS 文件做 Base64 编码（如
base64 -i main.js），生成字符串。 - 前端 JS 中写：
eval(atob('Zm9vKDIp'))或创建 script 标签写入解码后内容。 - ⚠️ 注意：
eval()有安全风险，且现代 CSP 策略通常禁止unsafe-eval；建议配合nonce或strict-dynamic使用 CSP。
三、AES 解密 + Blob URL 执行（中等强度）
比 Base64 更进一步：用对称加密（如 AES）加密脚本内容，前端用 Web Crypto API 解密后通过 Blob 创建可执行 URL。
立即学习“前端免费学习笔记（深入）”；
- 服务端用密钥加密 JS 源码（如用 Node.js 的
crypto模块），输出密文 + IV（初始向量）。 - 前端用
window.crypto.subtle.decrypt()解密密文（需先用importKey导入密钥）。 - 解密后得到
ArrayBuffer，转为字符串，构造Blob(['...'], {type: 'application/javascript'})，再用URL.createObjectURL(blob)生成 URL，动态创建 script 标签加载。 - ✅ 优势：避免明文暴露、绕过 CSP 的
unsafe-inline限制；❌ 劣势：密钥仍需硬编码或从服务端获取——若密钥暴露，整个方案失效。
四、关键提醒与替代思路
真正敏感逻辑不应放在前端。动态加载“加密脚本”只是障眼法，不是安全方案：
- 所有密钥、解密逻辑、算法都运行在用户设备上，均可被调试器捕获（如断点拦截
decrypt调用、Hookeval、内存 dump）。 - 推荐做法：将核心校验、授权、业务规则放在服务端；前端只负责 UI 和轻量交互，通过 API 与后端通信并验证响应签名/时效性。
- 若必须前端保护，可结合代码混淆（Terser）、控制流扁平化（JavaScript Obfuscator）、域名白名单（检查
location.hostname）、反调试（检测debugger、devtools开启状态）等多层叠加，但仍是“延缓破解”，非杜绝。
