企业官网建设流程全解析

干了这么多年跨端开发，我遇到过太多人在 uniapp 的调试和安装上栽跟头。明明照着官方文档一步步来，结果不是 HBuilderX 装完点不了“运行到手机”，就是调试器里一片空白，更别说真机同步时 ADB 死活识别不到设备。这篇文章就把我从零开始折腾 uniapp 调试环境、排掉各种安装坑、搞定真机与小程序调试、最后顺利打包上架的全过程整理出来，给正准备入坑或者已经被坑到怀疑人生的朋友一份可以直接照着抄的实操指引。

1. 装环境前先想清楚：HBuilderX 和 CLI 到底哪条路适合你

1.1 HBuilderX 安装的隐藏前提：App 开发版和插件别漏装

很多人下载 HBuilderX 时只看“正式版”三个字，下载完打开也能新建 uniapp 项目，但等到点“运行->运行到手机或模拟器”的时候，按钮是灰的，或者弹窗提示“当前 HBuilderX 未安装 App 开发版”。这不是你操作有问题，而是漏掉了最基础的一环。

HBuilderX 官网下载页有两个版本：标准版和 App 开发版。标准版只支持编辑、小程序编译、H5 编译，不支持 App 的真机运行、云打包、原生插件集成。所以如果你要做 App 端的调试、打包，必须下载 App 开发版。这个版本自带 Android 离线打包所需的 SDK 基础库、真机运行插件、App 资源打包工具等，比标准版大不少，但这是省心调试的前提。

下载解压后，推荐再做两件事：

• 在 HBuilderX 菜单栏“工具->插件安装”里，确认安装了“uni-app (Vue3)编译器”和“uni-app (Vue2)编译器”。Vue2/Vue3 项目之间切换时，如果缺了对应编译器，编译报错会非常难定位。
• 配置“外部命令”里的 adb 路径。HBuilderX 自带 adb，但 Windows 下经常出现自带 adb 版本和手机不匹配、识别不到设备的情况。我后来统一改用自己安装的 Android Platform Tools 里的 adb，问题少了一大半。

1.2 CLI 方式：团队协作和 CI/CD 友好，但对新手并不友好

如果你是在团队里做长期项目，或者要走自动化打包、持续集成，我更推荐用 CLI 方式创建项目。命令如下：

# 使用 vue3 + vite 模板 npx degit dcloudio/uni-preset-vue#vite my-vue3-project # 使用 vue2 模板 npx degit dcloudio/uni-preset-vue#vue2 my-vue2-project

然后进入项目目录安装依赖：

cd my-vue3-project npm install

跑起来也很简单：npm run dev:mp-weixin会把项目编译到dist/dev/mp-weixin，再用微信开发者工具导入这个目录就能调试。想跑 H5 就用npm run dev:h5，想跑 App 就用npm run dev:app，然后用 HBuilderX 打开项目根目录再运行到手机。

但这里有个新手必踩的坑：CLI 项目想用 HBuilderX 做 App 真机运行、云打包，必须用 HBuilderX 打开整个项目目录，而不是直接拖一个 src 文件夹进去；而且 HBuilderX 打开的窗口必须能识别到项目里的manifest.json和pages.json。我第一次用 CLI 方式建项目时，直接在终端里跑 dev:app，结果 HBuilderX 这边完全没有反应，折腾了好久才明白 App 端的运行和打包能力是绑定在 HBuilderX 工具链里的，这一点经常被文档一笔带过。

那到底选 HBuilderX 还是 CLI？我的建议很直接：单干、小团队、想快速出活，直接用 HBuilderX 图形界面；需要多人协作、代码评审、自动化流程，用 CLI，但这个前提是你已经对 uniapp 的编译流程和 npm 生态足够熟悉。两者并不是互斥的，你在 CLI 项目里装了依赖，照样可以时不时用 HBuilderX 打开来跑真机。

1.3 真机调试前的三项基础设施：ADB、微信开发者工具、模拟器

先说 ADB。Android 真机调试绕不开它。官方比较省事的做法是直接在 HBuilderX 里运行到 Android 手机基座，前提是手机开启开发者选项和 USB 调试。但我建议你还是单独装一个 Android Platform Tools，方便排查问题：

1. 下载 Platform Tools 压缩包，解压到一个路径里（比如D:\platform-tools）。
2. Windows 把这路径加入系统环境变量 PATH。
3. 手机连电脑 USB，弹窗允许 USB 调试后，命令行执行adb devices，能看到设备序列号就说明连接正常。

如果adb devices是空的，先换一根数据线试试，很多“识别不到设备”其实是线只能充电不能传数据。然后再检查手机上的“USB 调试”授权弹窗有没有点允许。

微信开发者工具也是必装的，小程序的调试离不开它。安装时注意三点：第一，安装路径不要带中文和空格，不然部分版本的编译插件会报错；第二，装完要登录微信扫码，并打开“设置->安全设置->服务端口”，不然 HBuilderX 无法自动唤起开发者工具；第三，项目第一次导入时，工具会提示“未配置 AppID”，选测试号体验即可，不影响本地调试。

模拟器方面，Android Studio 自带的 AVD 对新手来说太重，如果你只是快速验证 uniapp 页面效果，用 MuMu 模拟器或者腾讯的模拟器都行。不过模拟器上跑 uniapp 经常会有兼容性问题（比如摄像头扫码、蓝牙搜索），所以我建议模拟器只用来验证 UI 和基本交互，涉及系统 Api、原生能力的功能一定上真机。

2. 调试不是只有 console.log：四种运行环境的调试入口分别怎么开

2.1 H5 端：浏览器 F12 就是最大杀器

H5 是 uniapp 调试起来最顺手的环境，因为可以直接复用浏览器开发者工具。启动方式：HBuilderX 里点“运行->运行到浏览器->Chrome”，或者 CLI 项目跑npm run dev:h5。

在浏览器里调试有两个非常高频的用途：

• Network 面板看请求。跨端开发的网络请求问题（域名校验失败、参数序列化错误、响应拦截器报错），八成都得靠 Network 面板确认到底发出去了没有、返回了什么。尤其是 uniapp 的uni.request和 axios 这类封装一起用时，错误可能被拦截器吞掉，看 Network 是最直观的。
• Console 面板看页面报错和 Storage。H5 端uni.setStorage实际写入的是 localStorage，调试时可以手动在 Application 面板改值，模拟冷启动状态。

不过我要提醒一句：H5 环境正常不代表小程序和 App 正常。条件编译指令、App 端的 plus API、小程序端的 wx API，在浏览器里可能根本不会执行。我在开发时候的习惯是先用 H5 快速堆业务页面，但一涉及到原生能力，立刻切到对应端去验证。

2.2 微信小程序端：开发者工具的编译模式值得单独做一遍

小程序调试入口在微信开发者工具里。HBuilderX 里点“运行->运行到小程序模拟器->微信开发者工具”，会自动编译并拉起工具。如果没被拉起，按前面的方法检查服务端口。

进入开发者工具后，你会看到熟悉的调试面板：Console、Sources、Network、Storage、AppData。跟浏览器相比，小程序工具有两个对 uniapp 调试特别有用的地方：

• AppData 面板：可以直接查看和修改当前页面的 data。加了一个字段不想重新编译？直接在 AppData 里改，刷新后页面对应状态立即更新，这在调页面交互时省事不少。
• 编译模式：普通预览只能进首页，但你要调某个深层页面时，可以在开发者工具里选择“编译模式->添加编译模式”，填上启动页面路径和参数，能精确模拟从某个页面冷启动。这个特别适合调路由参数、分享落地页的问题。

另外，小程序端调试时要留意 uniapp 编译产物里的_this之类的代码（Vue2），报错堆栈和源码行号对不上是常态。真要看业务代码的调用关系，可以在 uniapp 源码里多打 console.log 在编译产物里搜对应字符串，定位到实际执行逻辑。这个土办法在排一些冷门问题时非常有效。

2.3 App 端：HBuilderX 内置日志、vConsole、chrome://inspect 三件套

App 端是 uniapp 调试的重灾区，因为它不像 H5 有小程序工具，也不像原生开发有 Android Studio 那么完整的调试链。我的做法是分三层排查：

第一层：HBuilderX 的“控制台”面板。真机运行后，代码里的console.log会输出到 HBuilderX 控制台，页面 JS 报错也会显示。但这套日志在部分 Android 机型上有延迟和丢失，不要全信。

第二层：vConsole。在项目里引入 vConsole（npm install vconsole，然后在 main.js 按条件编译引入），App 端页面底部会出现一个绿色按钮，点开就能看 console、Network、Storage、Element 等，体验和浏览器控制台很像。真机调试时用户手机上出问题，远程连不上，vConsole 是定位问题的第一选择。注意生产包记得用条件编译关掉。

第三层：chrome://inspect。Android 手机的 WebView 页面，可以用 Chrome 浏览器的chrome://inspect远程调试。手机连接电脑、打开 USB 调试后，在 Chrome 里打开这个地址，能看到手机上的 WebView 页面列表，点 inspect 就能像调试普通网页一样打断点、看 Network。这个对 uniapp 的 H5 模式页面、web-view 组件内部页面非常管用。需要提醒的是，这个功能依赖 Google 的调试协议，部分网络环境下服务端口连不上，但如果你本地环境能正常访问，这是我最推荐的 App 端 JS 调试方式。

如果涉及原生代码（原生插件、离线打包的 Android 工程），那就得用 Android Studio Logcat 看系统日志了。uniapp 的console.log在 App 端也会打印到uni-app这个 tag 下，用adb logcat -s uni-app可以过滤出应用日志。

2.4 条件编译：一次调试经历告诉我，日志也要分端输出

跨端项目有个很烦的情况：同样一段逻辑，在 H5 正常、小程序报错、App 又表现不同。看日志时如果不标明当前是哪个端，很容易被误导。我的习惯是封装一个统一的日志工具，内部用条件编译输出运行环境：

// utils/logger.js function log(...args) { // #ifdef H5 console.log('[H5]', ...args) // #endif // #ifdef MP-WEIXIN console.log('[MP-WEIXIN]', ...args) // #endif // #ifdef APP-PLUS console.log('[APP]', ...args) // #endif } export { log }

条件编译看起来简单，但它是 uniapp 调试思维的灵魂。很多问题不是代码写错了，而是你根本没有意识到当前代码在某个端根本不会执行。比如uni.request在 App 端默认会校验域名合法性，调试时需要在小程序后台把域名加入白名单；H5 端则没有这个限制。你不按端去区分，就会觉得“一会儿通一会儿不通”，没法排查。

3. 高频功能调试：路由参数、扫码、蓝牙这些“看着简单一调就炸”的玩意

3.1 路由参数获取：onLoad 拿不到值，十有八九是编码和解码的问题

uni.navigateTo传参是最基础的用法，但很多人第一次写都栽在对象参数上：

// 错误示例：直接传对象，拿到的是 [object Object] uni.navigateTo({ url: '/pages/detail/detail?id=' + item }) // 正确姿势：JSON 序列化 + encodeURIComponent uni.navigateTo({ url: '/pages/detail/detail?data=' + encodeURIComponent(JSON.stringify(item)) })

接收端：

onLoad(options) { if (options.data) { const item = JSON.parse(decodeURIComponent(options.data)) console.log('接收到的参数', item) } }

为什么 encode？uni.navigateTo的 url 本质上是一个链接，对象直接拼进去会被 toString 成[object Object]。中文、特殊字符、&、=这些符号如果不编码，onLoad的 options 解析就会错位。这是浏览器 URL 的固有逻辑，跨端都一样。

另一个常见场景是页面 A 通过uni.$emit传数据给页面 B，B 每次进入时监听。这个方案有一个坑：如果页面 A 在跳转前$emit，而 B 的onLoad里$on注册监听器晚于事件触发，就会漏收。稳妥做法是先在 onLoad 里同步处理路由参数，再配合uni.$emit/$on处理刷新数据的场景，不能只靠事件。

3.2 扫码结果是一串数字：先确认码的内容，再谈解析

热搜里有一条“uniapp scancode 扫码扫出来是一串数字”，这个现象背后的核心原因是：二维码的内容本身就是一串数字，跟你扫码没关系。很多硬件标签、设备序列号的二维码内容就是纯数字。真要判断扫码是否正常，可以先用微信扫同一个码，看微信扫出来是什么。微信如果也显示一串数字，那说明问题不在 uniapp，而是码的内容就是数字。

如果微信能正确识别成网址，你的 uniapp 扫出来却是数字，那再看你的扫码代码是不是用了uni.scanCode默认参数，没有对结果做处理。一般正确写法是：

uni.scanCode({ scanType: ['barCode', 'qrCode'], success(res) { const result = res.result // 如果是内容为 URL 的码，可以尝试解析 if (/^https?:\/\//.test(result)) { // 打开 webview 或跳转网页 } else { console.log('扫描结果：', result) } } })

另外，scanType不指定时，某些平台默认只扫二维码，条形码可能扫不到。如果你要支持条形码，记得显式声明。这个接口在不同端的表现差异也比较大，我曾经在 iOS 上扫码正常，但 Android 低版本手机上扫某些码会直接 fail，最后发现是相册扫码在部分机型没有权限，需要在 manifest 里声明相机权限。

3.3 蓝牙调试：先分清“业务问题”和“硬件问题”

蓝牙在 uniapp 里的调试是最让人头秃的，因为它涉及硬件、系统 API、业务三层。热搜里的“ble调试助手绑定(bond)”，就是大家在用蓝牙调试助手排查连接问题。

我的建议是：开始编写 uniapp 蓝牙代码之前，先用手机上的“nRF Connect”或“BLE调试助手”这类工具把硬件摸一遍。确认设备的广播名、Service UUID、Characteristic UUID、是否需要配对绑定、收发数据的格式，然后才轮到 uniapp 代码。

uniapp 蓝牙调试有这么几个高频问题：

• uni.openBluetoothAdapter返回10001或10012：通常是蓝牙没打开、或手机定位权限没开。Android 蓝牙扫描需要定位权限，这个必须在 manifest 里声明，并且运行时动态申请。
• 搜索不到设备：Android 9 以后系统对蓝牙扫描有权限限制，需要开精确定位权限；另外有些设备只广播不广播名字，搜索时会显示空名，你以为是没搜到。
• 连接成功后收发数据是乱码：绝大多数是 ArrayBuffer 和字符串转换的问题。蓝牙底层都是字节流，需要你按约定格式解析。比如自定义协议，接收时用new Uint8Array(buffer)处理，发数据时把按协议拼好的字节数组转成 ArrayBuffer 再 write。
• “绑定(bond)”逻辑：部分设备需要先配对再连接。如果在 uniapp 里createBLEConnection一直失败，先用蓝牙调试助手手动配对，确认设备确实允许绑定。

我记得有一次排查一个蓝牙秤的项目，问题是秤能连上但收不到重量数据。拿调试助手一测才知道，秤需要先发送一条查询指令才会主动上报数据。uniapp 代码完全没有问题，是业务理解少了“主动查询”这一步。这种问题，靠 console.log 是看不出来的，必须借助外部的调试工具做对照实验。

3.4 echarts 和图表调试：App 端优先走 renderjs

“uniapp 使用 echarts”是另一个搜索量很高的需求，也是调试起来容易莫名其妙的问题。在 H5 端、小程序端，直接用ec-canvas或 H5 的 echarts 都问题不大；App 端如果想流畅地渲染大量图表数据，可以用 renderjs 方案。

renderjs 的核心逻辑是用一个普通<script module="echarts" lang="renderjs">标签隔离出一个运行在视图层的 JS 环境，专门负责操作 DOM 和 canvas。数据通过 props 传进去，renderjs 监听数据变化后调用 echarts 的 setOption。调试时要注意：renderjs 环境里没有uni.的很多方法，也没有plus对象，不能在里面调用原生的 Toast、Storage、网络请求。它和主逻辑层的通信，只能靠this.$ownerInstance.callMethod把事件抛回逻辑层。

renderjs 调试的一个大坑是错误不可见。renderjs 环境内报错时，console 在部分版本的 App 上不会输出。我建议在 renderjs 里包一层 try/catch，把错误信息通过 callMethod 传回主逻辑层打印，不然报错了你都无从查起。

4. 页面渲染类的“疑难杂症”：白屏、软键盘、下拉刷新、视频播放

4.1 web-view 打开白屏：不是页面问题，是加载时序和样式层级问题

“uniapp 打开 webview 页面有过渡白屏”这个问题很典型。它分两种场景：

第一种是uni.navigateTo打开一个包含 web-view 的页面，白屏时间长。原因是 web-view 在系统底层创建原生 WebView 组件需要时间，而页面 JS 已经渲染完毕，原生 WebView 还没就位。缓解办法：

• 页面 onLoad 里先展示一个 loading 状态，等 web-view 的@loaded事件触发后再隐藏 loading。
• 给 web-view 设一个初始固定高度，避免页面内容撑开导致的二次布局抖动。
• 页面背景色和 web-view 所在容器背景尽量一致，减少视觉上的“闪白”。

第二种是 web-view 内部加载的 H5 页面白屏。这种情况大概率是 H5 资源加载失败，或者 H5 页面自己报 JS 错误。这时候用前面说的 chrome://inspect 直接连上去看 H5 页面控制台，是最快的定位手段。

另外提醒一个容易踩的坑：web-view 的 src 在 App 端是支持打开本地 HTML 的（放在hybrid/html文件夹下），但路径要写对。有人把 HTML 放在static里，结果 web-view 加载不到，白屏之后整个人都懵了。uniapp 约定，App 端本地 HTML 文件要放hybrid/html目录，引用路径用/hybrid/html/xxx.html。

4.2 小程序软键盘顶起遮挡查询内容：问题本质是键盘高度没有参与布局

“微信小程序 手机软键盘会遮挡住查询内容”这个热搜，核心原因是小程序页面在软键盘弹出时，可视区域高度变化，但你的输入框/按钮没有跟着调整。uniapp 在小程序端对软键盘的适配并不算聪明，我的做法是这样：

// 在页面 onLoad 里监听键盘高度变化 uni.onKeyboardHeightChange(res => { this.keyboardHeight = res.height // 在模板里给按钮区域动态绑定 padding-bottom })

对应模板：

<view class="search-bar" :style="{ paddingBottom: keyboardHeight + 'px' }" > <input type="text" placeholder="查询内容" /> <button>查询</button> </view>

还有一个容易被忽略的参数：input 的adjust-position属性。在小程序端，默认是 true，即键盘弹起会自动把 input 顶起来，但在某些复杂布局下反而和手动计算冲突。如果页面里用了position: fixed的底部输入框，建议adjust-position设为 false，全部交给onKeyboardHeightChange手动处理，这样布局完全可控。

4.3 下拉刷新和滚动冲突：问题往往出在 scroll-view 和页面的嵌套关系

“uniapp 下拉如何触动滚动屏而不触发页面下拉刷新”这个问题，我一开始看也愣了下，仔细一想是很多人在页面里嵌了scroll-view做竖向滚动，页面本身又开了enablePullDownRefresh。手指在 scroll-view 里往下拉到顶，继续拉，事件冒泡到页面，把整个页面的下拉刷新也触发了。

解决方案有这么几种：

• 页面需要整页下拉刷新时，不要在内部用一整屏的 scroll-view 包内容，直接用页面的原生滚动。uniapp 的普通视图在 App 端和小程序端是可以直接滚动的（页面本身就是一个滚动容器）。这样下拉刷新手势和内容滚动不会冲突。
• 如果必须用 scroll-view（比如要监听滚动位置、做分页加载），那就把页面的enablePullDownRefresh关掉，改用 scroll-view 的refresher-enabled属性，在@refresherrefresh里做刷新逻辑。

<scroll-view scroll-y refresher-enabled :refresher-triggered="triggered" @refresherrefresh="onRefresh" @scrolltolower="loadMore" > <!-- 内容 --> </scroll-view>

这是一个典型的“设计选择”问题：页面滚动和 scroll-view 滚动只能二选一作为主滚动容器，两个都想要，就会出现手势竞争。最稳的方案是主滚动用页面原生滚动，局部需要横向滚动的再用 scroll-view horizontal。

4.4 renderjs 里手机录的 mp4 无法播放：基本就是编码格式不兼容

“uniapp renderjs 手机录得 mp4 无法播放”这个问题看起来很偏，但背后是一个很实际的跨端问题：手机录制的 mp4 视频，编码格式大多数是 H.264，但部分 Android 机型的 WebView 对视频编码支持不完整，或者封装格式带了特殊音轨，导致 video 标签在 renderjs 环境里只能放画面没有声音，甚至整个视频黑屏。

我在实际项目里的处理方式是这样的：

• 先用系统播放器确认视频本身能播放。如果系统播放器也播放不了，那就是视频文件的问题，需要转码（用格式工厂或 FFmpeg 转成 H.264 + AAC 的 MP4）。
• 如果系统播放器正常，uniapp 的 video 组件却不正常，试试直接用plus.video.createVideoPlayer创建原生视频播放器，绕开 WebView 的视频解码链路。这在 Android 上尤其好用。
• renderjs 环境里不要尝试处理视频文件逻辑，比如通过 FileReader 把视频读成 base64 或者转 blob，再发给 video 标签播放，这会遇到极大的内存和兼容性问题。视频文件应该走静态资源或网络 URL。

5. 安卓上架、iOS 隐私合规：装好调好之后，“最后一公里”才是真正的门槛

5.1 manifest.json 里的这些东西，最好在项目初期就配好

App 端开发时，manifest.json是你最该重视的文件。很多人上架时遇到问题，回头看才发现是这里没配好。关键配置项如下：

• AppID：DCloud 开发者中心申请，云打包、真机运行都需要。没 AppID 就没法云打包，这个不要拖到最后一刻。
• 模块权限配置：比如蓝牙、相机、定位、推送，分布在 manifest 的可视化界面里。Android 在“App 模块配置”里勾选对应模块，iOS 在“隐私声明”里配置用途说明（如 NSCameraUsageDescription、NSBluetoothPeripheralUsageDescription）。漏配的典型现象是：开发环境真机运行一切正常，云打包之后调用 API 没反应。
• 图标和应用启动图：安卓各市场对图标尺寸有要求，不配置的话默认 DCloud 的图标，审核容易被拒。
• Android 打包的证书：云打包时需要生成签名证书。注意保存好 keystore，之后每次更新都要用同一个证书，丢了就没办法覆盖安装更新，只能换包名重新上架。

5.2 云打包和本地打包怎么选

云打包是 DCloud 的在线打包服务，在 HBuilderX 里点“发行->原生 App 云打包”，填好证书、勾选模块，等几分钟出包。对绝大多数团队来说，这是效率和成本最优的选择。但云打包有几个限制：打包排队时间不定、原生插件只能使用 DCloud 插件市场的插件，不能注入自定义原生代码。

本地打包（离线打包）适合要集成自己原生 SDK 的团队。流程大致是：在 DCloud 官网下载对应版本的 Android 离线打包 SDK，用 Android Studio 打开，把 uniapp 编译出的app-resources资源放进工程，再编译出 APK。这套流程对 Android 原生开发能力有要求，新手不建议一上来就搞，会在地图、推送等第三方 SDK 的引入上被折磨到怀疑人生。

我个人建议：除非你真的要写原生插件，否则先用云打包把产品和业务流程跑通，等确定需要深度定制原生能力了，再迁移到离线打包。

5.3 安卓应用市场上架：软著、隐私政策、加固一个都不能少

上架安卓应用市场前，你需要准备：

• 软件著作权证书：大部分安卓市场要求软著才能上架。没有软著的话，部分市场支持用电子版权认证代替（电子版权认证下证快，几十块钱搞定），但主流市场对软著的要求越来越严。
• 隐私政策：应用内必须有一个能访问到的隐私政策页面，说明收集哪些信息、如何使用、如何联系开发者。首次启动时需要弹窗让用户同意隐私政策和用户协议。这个不接好，大概率被市场审核打回。
• 应用加固：上架前可以做加固，防止反编译，尤其是金融、电商类应用。市场一般都有推荐的加固服务。
• 各市场的差异化要求：每个市场的审核标准不完全一样。比如有的市场要求应用内必须有一级分类的“应用管理”功能，有的要求账号注销入口必须在设置页内而不是只在隐私政策文字里。多看看同类型应用的做法，比自己盲猜高效得多。

5.4 iOS 用户不同意隐私政策时退出 App 的代码实现

“uniapp ios app 当用户不同意隐私政策及用户协议时退出 app”这个需求在 iOS 审核中几乎是必查项。首次启动时弹出隐私协议弹窗，用户不同意，App 应该退出，且不能有强行让用户同意的诱导。uniapp 里可以直接这样写：

uni.showModal({ title: '提示', content: '需要同意隐私政策后才能继续使用App', showCancel: true, cancelText: '不同意', confirmText: '同意', success: (res) => { if (res.confirm) { // 存储同意状态，继续初始化 uni.setStorageSync('privacyAgreed', true) } else { // 用户不同意，退出App plus.runtime.quit() } } })

注意：plus.runtime.quit()只在 App 端可用，条件编译一下：

// #ifdef APP-PLUS plus.runtime.quit() // #endif // #ifdef H5 || MP-WEIXIN // H5和小程序里不让主动关闭，只能引导用户手动退出 // #endif

iOS 审核对“同意后才能使用”的隐私弹窗还有几个细节要求：弹窗出现前不能初始化任何采集用户信息的 SDK（包括统计 SDK），所以这个弹窗最好放在 main.js 的最前面判断，没有同意状态就不初始化分享、统计、推送等插件。并且弹窗文案要和 App 市场上的隐私政策链接保持一致，不一致会被认定为隐藏收集信息，审核被拒就是这么来的。

5.5 还有个经常被问到的点：上架后用不用做“开机启动”

热搜里有“uniapp 开机启动 app”，这个功能在 Android 端可以做成设备管理类应用的场景（比如电子班牌、门店广告机）。实现方式一般是在原生插件里监听开机广播，然后拉起 App 主界面。纯 uniapp 代码做不了这个，因为 HBuilderX 的云端插件市场有开机启动插件，你也可以自己写原生插件实现。

这类需求的核心逻辑：不是“App 自己开机启动”，而是“系统开机会向已注册接收 BOOT_COMPLETED 广播的 App 发消息，App 的广播接收器收到后启动应用”。所以测试时别指望普通安装的 App 能开机自启，部分国产 ROM 还需要在系统设置里手动授予“自启动”权限。这个在研究时要注意，不要把测试不通过归结为代码问题。

一些补充：调试和安装这件事，最终拼的是“定位问题的路径”

写到最后，我想分享一个项目收尾阶段的体会。刚开始接触 uniapp 时，我会觉得它的调试和安装真麻烦，“为什么不能像网页一样写完了就刷新呢”？但经历的项目多了以后发现，跨端开发的麻烦并不在 uniapp 本身，而是它承载了太多不同平台的运行环境——H5、小程序、App 各有各的权限模型和接口实现，调试工具自然没法统一。

现在面对一个“装好了跑不起来”的项目，我的排查顺序已经变成一套固定路径：先看编译是否通过，再看控制台有没有 API 报错，然后看请求是否发出去、返回值是什么，最后用对应端的高级工具（浏览器 F12、开发者工具 AppData、chrome://inspect、logcat）做深入定位。安装问题就先检查工具链是否完整：编辑器版本、编译器插件、adb 连接、开发者工具端口，逐项排除，基本没有查不出来的问题。

如果你正在搞 uniapp，建议你把这篇文章里提到的工具链一次性装到位，项目初始化时就把条件编译的日志工具、vConsole 的引入开关、manifest 的关键配置项都弄好。磨刀不误砍柴工，后面真的会遇到无数个调试问题，那时候你就会感谢自己当初花掉的那一下午。