企业官网建设流程全解析

• 示例工程
• 前端
• 移动开发
• 跨平台

App 安装包本质上是一个可被解压的压缩包，前端资源（js、nvue 等）通常以明文存放在安装包中，解压即可查看源码，存在敏感信息泄露风险。本文以 uni-app 官方文档《App 的 js/nvue 文件原生混淆》为核心，系统讲解 uni-app 与 5+ App/Wap2App 项目中 js/nvue 文件原生混淆的配置方法、云端打包流程、使用限制，并结合仓库内 客户端安全 API 与 uni安全加固 文档，给出从"文件级加密"到"整包加固"的完整安全实践方案。读完本文，你将掌握在 manifest.json 中配置原生混淆、正确处理 vue/nvue 页面共享加密 js、以及针对 iOS WKWebview 特殊配置等全部实战技能。

一、为什么需要原生混淆：安装包解压即源码

App 的安装包（APK / IPA）都可以被解压。前端资源，一般都是明文存放在安装包中，攻击者使用常见的解压与反编译工具即可直接阅读业务逻辑、接口地址、密钥等敏感信息。为防止解压后泄露敏感信息，需要进行安全处理。

由此 DCloud 提供了 App 端的 js/nvue 文件原生混淆能力：

• 5+ App / Wap2App：支持对指定的js 文件进行原生混淆；
• uni-app：支持对指定的nvue 文件（以及 v3 编译器下 vue 页面中引用的独立 js 文件）进行原生混淆。

原生混淆后的安装包，解压后看到的都是乱码，从源头阻断直接阅读源码的可能。

二、使用原生混淆前必须明确的 4 条注意事项

在动手配置之前，请务必理解以下限制，它们直接决定混淆方案的设计：

1. 没有绝对的安全。非常重要的信息（如支付密钥、核心业务数据）应保存在服务器端而非前端，前端混淆只能提高破解成本，不能提供绝对保护。
2. 运行期解密会影响执行性能。应用运行期间，被混淆的资源需要在运行时解密还原，这会增加 CPU 开销。因此不建议全包混淆，仅挑选需要保护的个别文件处理即可。
3. wgt 包支持情况。uni-app 项目制作 wgt 热更新包不支持原生混淆加密（即使配置也不会生效），HBuilderX 3.1.0+ 版本后才支持。
4. 只有正式云打包才生效。为了保证加密数据的安全性，加密算法和 key 不对外公开，因此：
   • 离线打包无法支持原生混淆加密；
   • 标准基座或自定义基座真机运行也不支持原生混淆加密；
   • 只有正式云打包才支持原生混淆。

这意味着原生混淆的验证必须走正式云打包流程，无法在本地调试阶段直接观察效果。

三、uni-app 项目的原生混淆配置

3.1 配置入口：manifest.json 源码视图

打开项目根目录的manifest.json文件，切换到"源码视图"，按不同项目类型在对应节点下配置。uni-app 项目使用"app-plus"节点，5+ App/Wap2App 项目使用"plus"节点。

3.2 为什么 uni-app 只支持"独立文件级"混淆

uni-app 的 js 运行在独立的 jscore 中，而不是 webview 中，所以不受 iOS 平台 WKWebview 不支持原生混淆的限制。

但需要注意的是：uni-app 的 vue 页面中的 js，是整体编译到一个大 js 文件中的。它经过编译，已经不再是 vue 源码，但还不是乱码。如果对这个统一的大文件进行混淆，会显著影响性能。

因此 uni-app 只支持独立混淆 nvue/js 文件，这也正是下面两种配置方式（vue 页面独立 js、nvue 文件）的设计出发点。

3.3 混淆 nvue 文件（HBuilderX 2.3.4+）

从HBuilderX 2.3.4 版本开始，uni-app 项目支持对 nvue 文件进行原生混淆。在"app-plus" -> "confusion" -> "resources"节点下添加要混淆的 nvue 文件列表：

"app-plus": { "confusion": { "description": "NVUE原生混淆", "resources": { "pages/barcode/barcode.nvue": { }, "pages/map/map.nvue": { } } }, // ... }

配置说明：

• resources下的键名为 nvue 文件路径（相对于应用根目录）；
• 值为空 JSON 对象（大括号{}），仅起占位作用。

联动混淆规则：如果 nvue 页面引入了外部的 js 文件，该 js 会被一起原生混淆。但如果这个 js 还被其他不加密的文件引用，则该 js 仍然会暴露在安装包中——即"只要有一个入口不加密，这份 js 就无法保密"。

3.4 混淆 vue 页面中引用的 js 文件（HBuilderX 2.6.3+ v3 编译器）

从HBuilderX 2.6.3+ 版本开始，uni-app 项目使用v3 编译器支持对 vue 页面中引用的 js 文件进行原生混淆。开发者可以将要保护的 js 代码写到独立的 js 文件中，在 vue 页面中使用import引用；另外main.js 也可以原生混淆。

在manifest.json文件中添加要混淆的 js 文件列表：

"app-plus": { "confusion": { "description": "原生混淆", "resources": { "common/test.js" : {} } }, // ... }

在 vue 文件中引用混淆的 js 文件：

import test from '../common/test.js'; //test.join(); //调用引用js中的方法

重要联动规则：如果此 js 同时被 nvue 页面import引用，则nvue 页面也需要配置原生混淆才有效（否则 nvue 页面会以明文方式把该 js 打进包内）。

老版本（2.6.3 之前）：不支持 vue 页面的原生混淆，开发者只能将要保护的 js 代码写到 nvue 文件中进行保护。

3.5 vue 页面和 nvue 页面同时使用加密 js 中的数据或方法

适用版本：HBuilderX 2.6.3+ 版本 v3 编译器。

如果一份加密 js 里的数据或方法需要同时被 vue 页面和 nvue 页面使用，可以按如下方式处理：

1. 配置该 js 加密（见 3.4 节）；
2. 在App.vue中引用该 js，把该 js 中的数据或方法赋值给全局对象，如globalData；
3. vue 和 nvue 中通过访问getApp()来访问共享数据或方法即可，无需配置 nvue 页面加密。

这种方式既保护了核心 js 的源码，又通过全局对象实现了跨页面共享，避免为每个 nvue 页面重复配置混淆。

3.6 多端发布建议：善用条件编译

如果要发布多端（App、小程序、H5 等），要保护的 js最好写在app-plus的条件编译中，否则发布到其他端时，仍然无法原生混淆（且会因条件编译缺失导致逻辑错乱）。例如：

// #ifdef APP-PLUS import test from '../common/test.js'; // #endif

3.7 webview 组件的特殊限制

注意：uni-app 中 vue 页面的 webview 组件支持加载使用加密混淆的hybrid、static目录中的 js 文件，而 nvue 页面的 webview 组件不支持。

如果你的业务依赖 nvue 页面内嵌 webview 加载本地 js，请评估该 js 是否需要保密，必要时改用 vue 页面承载 webview。

四、5+ App / Wap2App 项目的原生混淆配置

4.1 仅支持 js 文件混淆的原因

应用运行期间，页面打开时需要消耗更多时间进行混淆文件还原。为减少对运行速度的影响，5+ App / Wap2App 仅支持对 js 文件进行原生混淆（不支持对 nvue 之类文件混淆，因为该体系中不存在 nvue 概念）。

4.2 基础配置（plus 节点）

在"plus" -> "confusion" -> "resources"节点下添加要混淆的 js 文件列表：

"plus": { "confusion": { "description": "JS原生混淆", "resources": { "js/common.js": { }, "js/immersed.js": { } } }, // ... }

同样，resources下的键名为 js 文件路径（相对于应用根目录），值为空 JSON 对象（大括号）。

4.3 iOS 平台 WKWebview 支持（HBuilderX 2.6.11+，iOS 11+）

WKWebview 使用了更加严格的安全机制。从HBuilderX 2.6.11+ 版本开始，在 iOS 11+ 设备上使用 WKWebview 也可以支持 JS 原生混淆，但有两个关键要求：

要求一：必须使用自定义协议头plus-confusion://引用混淆 js

使用原生混淆的 js 文件，在 html 页面中必须使用自定义协议头plus-confusion://来引用：

<script type="text/javascript" src="plus-confusion://../js/common.js"></script> <!-- plus-confusion:// 后面为js文件路径，相对于当前html页面的路径 -->

要求二：开启 supportWKWebview 并配置最低系统版本

在manifest.json的"plus" -> "confusion" -> "resources"节点下添加要混淆的 js 文件列表，并在"confusion"节点下添加"supportWKWebview": true支持 WKWebview：

"plus": { "confusion": { "description": "JS原生混淆", "supportWKWebview": true, "resources": { "js/common.js": { } } }, "distribute": { "apple": { "deploymentTarget": "11.0" //设置应用仅支持iOS11及以上设备 //... } } // ... }

由于自定义协议plus-confusion://仅在iOS 11 及以上设备才支持，建议配置应用支持的最低版本deploymentTarget为11.0。

兼容性警告：iOS 平台 WKWebview 需 iOS 11+ 系统才支持原生混淆。5+ App / Wap2App 项目如果要兼容 iOS 11 以下设备，只能强制使用 UIWebview 内核，但苹果已宣布废弃 UIWebview。如对原生混淆很重视，从长远考虑，建议改造升级到 uni-app。

五、提交云端打包：最后一步不可省略

配置好原生混淆的文件列表后，需要提交云端打包。注意：在 App 云端打包对话框中需要勾选"对配置的 js 文件进行原生混淆"，混淆能力才会真正生效。

再次强调打包阶段的限制：

• 为了保证加密数据的安全性，加密算法和 key 不对外公开，因此离线打包无法支持原生混淆；
• 标准基座、自定义基座真机运行均不支持，必须使用正式云打包。

熟悉原生的开发者，也可以将敏感信息存放于原生代码中，再与 js 进行交互，从架构层面进一步降低前端暴露面。

六、纵深防御：原生混淆之外的安全组合拳

原生混淆解决的是"前端资源明文泄露"问题，但 App 安全是体系化工程。结合仓库内的安全专题文档，建议按如下层次叠加防护：

6.1 客户端安全 API + 原生混淆联动

仓库文档 客户端安全API 提供了plus.navigator.getSignature（应用签名标识校验）、plus.navigator.isSimulator（模拟器检测）、plus.navigator.isRoot（越狱/root 检测）、plus.networkinfo.isSetProxy（代理检测）等安全 API。

其中特别提示：为了防止 js 检验代码被反编译篡改，建议将签名校验代码放到独立 js 文件中，并配置 js/nvue 文件原生混淆加密，或者使用 apk 加固处理。这正是原生混淆在真实项目中的典型落地场景——签名校验逻辑如果明文暴露，攻击者可直接删改校验代码实现绕过，混淆后则大幅提高篡改成本。

6.2 整包加固：uni 安全加固

对安全性要求较高的开发者，除了对前端 js 进行加密外，还应该对整个 apk 再进行一次加固。推荐 uni安全加固，目前由蚂蚁小程序云提供支持，可有效提升应用整体安全性：

• 支持 dex 整体加壳加固，提高应用被逆向、破解的难度；
• 提供签名校验、防重打包能力，防止应用被二次打包后投放应用市场；
• 支持本地资源加密，保护敏感数据与核心算法逻辑；
• 提供测试版（免费，App 有效期 15 天）与正式版（按次收费）两种类型，建议先用测试版验证再切换正式版。

6.3 安全检测报告的处理原则

仓库文档 Android平台安全漏洞风险处理 指出：安全平台检测出的漏洞风险并不代表真实存在安全漏洞，例如 WebView 远程代码执行漏洞仅存在于 Android 4.2 及以下版本，而 HBuilderX 发布 App 的最低要求版本为 Android 4.4。对于存在漏洞风险问题的基本解决方案是使用 APK 加固（推荐 uni安全加固）；若加固仍不能解决，可按该文档要求整理完整安全检测报告发帖反馈。

6.4 完整安全方案定位

整套安全链路可总结为三层：

七、常见问题速查

Q1：为什么配置了混淆，解压安装包还是能看到明文？请依次排查：是否走了正式云打包（标准基座/自定义基座/离线打包均不支持）；是否在云端打包对话框中勾选了"对配置的 js 文件进行原生混淆"；文件路径是否相对于应用根目录且与实际路径一致。

Q2：一份 js 被多个页面引用，加密后还有泄露风险吗？存在。只要该 js 还被任意一个未加密的文件（如未配置混淆的 nvue 页面、vue 页面）引用，该 js 仍会以明文出现在安装包中。规则是：所有引用它的入口都必须一并加密，或者通过 App.vue + globalData 的共享方式（见 3.5 节）规避。

Q3：wgt 热更新包能带混淆资源吗？不能。uni-app 项目制作 wgt 包不支持原生混淆加密（HBuilderX 3.1.0+ 版本后才支持）。

Q4：iOS 上混淆的 js 为什么不生效？5+ App/Wap2App 项目中，iOS 11+ 且使用 WKWebview 时，必须开启supportWKWebview: true并在 html 中改用plus-confusion://协议引用；uni-app 项目 js 运行在 jscore 中，不受 WKWebview 限制，只需确认 nvue/js 文件本身已正确配置。

Q5：混淆会影响性能吗？会。运行期对资源代码解密是影响执行性能的，不建议全包混淆，仅挑选需要保护的个别文件处理即可。

八、结语

原生混淆是 uni-app / 5+ App 前端资源安全的第一道防线，它以极低的接入成本（仅需配置confusion节点 + 云端打包勾选）将核心 js/nvue 文件从"明文可见"变为"解压乱码"。但要清醒认识到：没有绝对的安全，混淆 + 客户端安全 API 校验 + 整包加固的组合，才是面向真实威胁的完整防御体系。建议在项目初始化阶段就按本文方案规划好待保护文件清单，将安全能力前置到架构设计之中。

• 示例工程
• 前端
• 移动开发
• 跨平台