uni-app 无法主动防范抓包，只能通过证书固定、敏感数据加密、禁用调试等方式提高抓包门槛；其请求易被抓因WebView依赖系统HTTP栈且无默认证书校验，HTTPS不防本地代理解密。
uni-app 本身无法主动“防范”抓包代理工具——只要请求走 HTTP/HTTPS，且设备网络可被中间人（MITM）控制，抓包就天然可行。真正能做的是提高抓包门槛、限制明文泄露、阻断非预期调试路径。核心思路不是封死所有可能，而是让抓包成本远高于收益。
为什么 uni-app 的请求默认容易被抓
uni-app 编译后的安卓/iOS App 本质仍是 WebView + 原生容器，网络请求最终调用系统级 HTTP 栈（Android OkHttp / iOS NSURLSession），不自带证书绑定或流量混淆。只要用户手动配置代理 + 安装根证书（如 Proxyman、Charles、Fiddler 的证书），所有 uni.request、WebSocket、甚至 native.js 发起的请求都会被透明捕获。
常见误判是以为「用了 HTTPS 就安全」——其实 HTTPS 只防传输窃听，不防本地代理解密。关键点在于：客户端是否校验服务端证书有效性，以及是否信任了攻击者注入的中间人证书。
强制证书固定（Certificate Pinning）
这是最有效的防线，原理是让 App 只接受特定证书或公钥，拒绝任何代理伪造的证书链。uni-app 本身不提供 API，需依赖原生层实现：
- Android：在
android/app/src/main/res/xml/network_security_config.xml中配置pin-set，并启用android:networkSecurityConfig指向该文件 - iOS：使用
NSURLSessionDelegate实现urlSession(_:didReceive:completionHandler:)，在回调中比对服务器证书的 SHA-256 公钥指纹 - H5/小程序端无法做证书固定——它们运行在浏览器或微信 WebView 沙箱内，无权干预 TLS 握手
注意：uni.request 不透出底层证书校验钩子，所以必须通过原生插件（如自定义 uniModule）或修改打包后的原生工程来注入逻辑。直接在 JS 层写 checkServerTrusted 是无效的。
避免敏感数据走明文网络通道
即使被抓包，也要确保关键字段不可读。这不是防抓包，而是降低被抓后的危害：
- 登录态 token、手机号、身份证号等，不应作为 URL 参数或 JSON body 明文传递；应改用服务端签发的短期加密票据（如 JWT 加密 payload + 验证签名）
- 接口响应中避免返回原始密码、密钥、未脱敏银行卡号；uni-app 封装的请求层（如
http.js）应在success回调前做字段过滤或解密 - 对称加密敏感字段时，密钥不能硬编码在 JS 中（
manifest.json或uni.getSystemInfoSync()获取设备指纹动态生成密钥更稳妥）
特别提醒：uni-app 的条件编译（如 #ifdef APP-PLUS）无法阻止反编译后看到 JS 逻辑——App 打包后 JS 仍以明文或简单混淆形式存在，密钥提取成本极低。
禁用调试模式与移除调试入口
很多抓包行为依赖开发者主动开启调试。切断这些入口能筛掉大量非专业抓取：
- 发布前确认
manifest.json中"debug": false，且"usingComponents": true（禁用 HBuilderX 自动注入的调试面板） - 删除所有
console.log、debugger、uni.showModal弹窗调试代码；它们可能被逆向者复用为日志输出通道 - 安卓端检查是否误开启了
android:debuggable="true"（在AndroidManifest.xml中），这会让 ADB 调试和部分抓包工具获得更高权限
真机环境下，仅靠 JS 层逻辑无法阻止用户手动设置 WiFi 代理——那是系统级行为。所谓「检测代理」的 JS 方案（如尝试连接 localhost:8888）极易被绕过，且在 iOS 上根本不可行。
最常被忽略的一点：证书固定必须随服务端证书轮换同步更新 App，否则会导致大面积白屏。别把 pinning 当成一劳永逸的开关，它是个需要运维配合的活儿。
