为什么 H5 封装包更容易在审核环节卡住
H5 封装成 App 的典型结构是：原生壳负责启动、权限、更新和分享，WebView 负责加载远端或本地页面。业务迭代快，但审核看的是“这个安装包本身是否完整、可解释、可复现”。一旦壳与页面内容脱节，审核方看到的就是一个行为不稳定的应用。下面四类问题最常被问到：缓存、外链、权限申请、壳与内容一致性。
缓存：别让审核看到旧页面
WebView 默认会缓存静态资源，部分团队还会在壳里做离线包。审核环境网络与用户环境不同，容易出现“打开是白屏”“内容与描述不符”“更新后仍是旧版本”的情况。
- 版本可识别：在设置页或关于页展示壳版本号与 H5 资源版本号，便于审核与客服定位。
- 缓存策略分层：HTML 入口走协商缓存，带 hash 的静态资源可长缓存；离线包要有明确的失效与回滚机制。
- 首启兜底：远端加载失败时要有本地兜底页和重试入口，避免直接白屏。
- 清理入口：提供“清除缓存”按钮，审核反馈内容异常时可自助排除。
如果壳内还涉及下载页、更新包分发，建议把稳定性保障单独做成清单，可参考站内的分发与稳定性相关服务说明。
外链：跳转边界要写清楚
H5 页面里出现第三方链接很常见，但审核关注的是：跳出去之后还是不是你的应用在负责。建议在 WebView 层统一拦截：
- 白名单内的业务域名在应用内打开；
- 支付、登录授权等敏感流程使用系统浏览器或官方 SDK；
- 外部链接统一走确认弹层，明确提示“将离开当前应用”；
- 禁止通过外链绕过应用内购买或诱导下载其他安装包。
另外，WebView 的 URL 校验要在原生侧做，不能只靠前端 JS 判断，否则被篡改的页面可以绕过限制。
权限申请：按需、可解释、可拒绝
H5 封装包常见的权限问题是“一次性申请一堆”。相机、相册、定位、通知、存储往往只在个别页面用到，却在启动时全部弹出。审核侧容易判定为过度申请，用户侧也容易直接拒绝。
- 把权限申请推迟到实际使用场景，例如点击“拍照上传”时再请求相机；
- 每次申请前给出用途说明，拒绝后提供降级路径；
- 检查第三方 SDK 是否在初始化阶段静默申请权限；
- 隐私政策中列明的权限必须与安装包实际申请一致。
壳与内容一致性：审核看到的就是用户看到的
这是 H5 封装模式最核心的风险点。审核时加载的页面，必须和用户实际使用的内容一致，不能出现“审核期展示 A 内容、上线后切换 B 内容”的做法。可落地的做法包括：
- 应用名称、图标、描述与首屏内容保持一致，避免壳是一个工具、内容却是另一类服务；
- 远端配置要有版本记录，重大内容变更同步更新商店描述；
- 涉及账号、付费、内容分发的功能，确保在审核环境下可完整走通；
- 保留壳与 H5 的对应关系文档，便于应对复审问询。
分发环节同样如此：不同渠道的安装包如果壳版本不一致，容易出现同一版本号、行为不同的情况，后续排查成本很高。关于安装包与签名链路的常见问题，可参考站内服务页面中的说明。
上线前自查清单
- 首启断网、弱网、缓存命中三种场景各测一遍；
- 列出全部外链域名，确认拦截规则与跳转提示；
- 逐项核对权限申请时机与隐私政策文本；
- 确认审核环境可访问的页面与用户侧一致；
- 记录壳版本、H5 版本与渠道包的对应关系。
H5 封装不是把网页塞进 WebView 就结束，审核与分发看的是边界是否清晰。把缓存、外链、权限和内容一致性这四件事做成固定检查项，比事后补救更省成本。