2026年了，Uni-app 打的 App 一提审就说隐私弹窗没前置，我明明弹了，是 SDK 先跑了吗？

Uni-app 打的 App 被应用市场驳回，提示「启动前未向用户展示隐私政策」，多数情况不是没做弹窗，而是弹窗出现的顺序错了：它排在统计、推送、地图等三方 SDK 初始化之后，或者排在首页请求之后。审核看的是首次启动、覆盖安装、无同意记录这三类状态下，同意之前有没有发生信息读取行为，而不是你有没有一个弹窗组件。2026 年各市场的隐私合规口径趋严，顺序问题比弹窗样式更容易导致驳回。

为什么被驳回的常常是顺序，而不是弹窗本身

Uni-app 的 App 端启动链路大致是 main.js → App.vue 的 onLaunch → 首个页面的 onLoad 与 onReady。不少项目为了「让首页更快」，把 SDK 初始化、远程配置拉取、热更新检查统统塞进 onLaunch，弹窗则等页面渲染完再弹。在代码里这两件事互不相干，审核侧看到的却是另一件事：弹窗还没出现，设备信息、剪贴板、安装列表可能已经被读过一次。

隐私弹窗的本质不是一张界面，而是一道闸门：它把会读取用户信息的行为统一挡在同意之后。想判断自己的项目是闸门还是装饰，做一个动作就够了——在一台干净设备上首次安装并打开，同时看网络请求和运行日志，看同意之前有没有请求发出。合格线是：同意前无采集、拒绝后基础功能可用、隐私政策能二次打开，三条里缺一条就容易被判不过。

• 首次安装：最容易过，也最容易被漏测
• 覆盖安装、清数据后启动：老用户升级路径经常没人验
• 冷启动直达页：扫码、推送、分享链接直接进二级页，弹窗常挂不出来
• 拒绝之后：要能继续浏览，不能白屏、闪退或直接退出

可命名的排查框架：一张清单、两道闸、三份证据

把这件事拆成「清单—时机—证据」，是因为三个环节的负责人往往不是同一个人：清单要产品确认，时机由前端实现，证据由运营在市场上传。混在一起讨论，结果通常是「都改了但还是被驳回」，来回扯皮。

清单层：SDK 与权限对账

1. 罗列项目里全部三方 SDK 与原生插件，包括统计、推送、地图、支付、客服、热更新
2. 逐个标注：读什么信息、什么时机初始化、能不能延迟到用户同意之后
3. 与应用市场后台申报的权限清单、SDK 清单逐条对齐

注意：清单与实际行为不一致，是驳回里占比很高的一类原因，它跟代码写得好不好基本无关，属于文档与实现脱节。

时机层：两道闸

• 前置闸：在首个业务页面渲染前拦截，把 SDK 初始化挂到用户同意的回调之后，而不是让它跟着 onLaunch 自己跑
• 兜底闸：拒绝之后走降级路径，非必要信息不收集，基础功能可用，并保留再次同意的入口

注意：小程序的授权弹窗和 H5 的 Cookie 提示，跟 App 这套不是一回事。用条件编译隔离在 APP-PLUS 块里，别让一套逻辑硬扛三端，否则改一端坏两端。

证据层：三份能提交的材料

• 弹窗文案与隐私政策全文，逐项对得上实际收集项
• 拒绝、撤回同意的操作路径截图或录屏
• 各市场后台的权限与 SDK 申报记录

这三份通常不是前端一个人能定的，交付时要先核对，不然很容易出现代码改完了、文案还在等确认的卡壳。

交付现场：一次驳回大概要搭进去多少时间

在项目里常见的情况是：审核排队本身常见 1-3 个工作日，被驳回后要改文案或调顺序，然后重新云打包、重新提交、再排队。约束条件往往是活动节点已经定了、文案要等产品与法务确认、素材还差几页。做法是在提审前先用一台干净设备跑三遍——首装、覆盖安装、清数据后启动，并把同意前后的日志各截一次。按企业项目交付习惯，这类自检通常会被放进提审前置清单。代价也很直接：漏掉这道自检，来回一轮常在一周左右，赶上推广节点就只能延后上线；更麻烦的是抽检，上线后被要求整改，还可能牵出下架。这里的经验区间是：从驳回通知到重新过审，顺利时 2-4 个工作日，遇到文案法务确认或市场加审，常见区间会拉到 5-10 个工作日。

几个反复出现的坑

• 用延时弹窗代替顺序控制：setTimeout 之后，SDK 其实已经跑完了
• 只在首页 onLoad 里弹：冷启动直达二级页时弹不出来
• 拿 uni.showModal 当隐私弹窗：按钮文案与样式不可控，部分市场不认
• 隐私政策指向 webview，但地址打不开或走了内网
• 隐私政策内容更新了，App 里没做二次确认
• 只测了 App 端，忘了同一套代码的 H5 与小程序端各有各的规则

自写弹窗组件和第三方合规插件，怎么选

• 自写组件：可控性高，能对齐品牌与交互，缺点是每个市场的规则变化要自己跟。接入经验区间约 0.5-2 人日，不含文案与法务确认时间。适合有长期自维护团队的项目。
• 第三方合规插件：对接快，规则更新跟着插件走；代价是会引入额外 SDK 与包体，还要核对这些 SDK 的收集声明会不会加重申报负担。接入经验区间约 1-3 人日。适合一次性交付、甲方没有专职合规同学的项目。
• 选错方向的代价：自写却没人维护规则，几个月后可能又因为市场新规被驳回；用插件却没核对声明，市场后台填的和实际收集的对不上。

适用场景与边界

需要认真做这一层的典型情况：要上国内常见应用市场、接了推送或统计类三方 SDK、有账号登录或支付功能、由外部团队交付后甲方自行运营。反过来，不上架的测试包、企业内部分发、纯 H5 或纯小程序项目，通常不必照搬 App 这套流程，按各自平台规则处理即可。另外要说清一点：隐私弹窗是上架门槛，不是体验优化项，它解决的是能不能过审，不解决留存和转化，别指望它顺带把数据做上去。

常见问题

Uni-app 的隐私弹窗必须在启动页之前出现吗？

常见做法是在首个业务页面渲染前、任何三方 SDK 初始化前弹出，优先于首页数据请求；具体时机以各应用市场当期审核规范为准。

用条件编译区分 App 和小程序，维护成本会不会翻倍？

只隔离差异部分即可，把弹窗与 SDK 初始化放进 APP-PLUS 块，公共逻辑照常复用，维护量通常在可接受范围内。

用户点了拒绝，还能继续用 App 吗？

按常见审核口径，拒绝非必要收集后基础功能应可用；只有核心功能确实依赖时才提示，并给出再次同意入口，不能直接退出。

云打包和本地打包，在隐私这块有区别吗？

实现上没有本质区别，但云打包会带上平台预置的原生模块，弹窗顺序更容易被忽略，提审前建议两种方式各验一遍。

下一步：把「干净设备首装、同意前无采集、拒绝后可用、政策可二次打开」这四条写进提审前置清单，交给产品、前端、运营三方各确认一次。这套流程适合要上架国内市场的 App；纯内部测试包、纯 H5 或小程序项目不必照搬。规则以各应用市场当期审核规范为准。