壳不是问题，壳里装的东西才是
把 H5 页面用 WebView 封装成 App，是很多团队验证需求、快速上架的低成本路径。技术上它只是套了一层壳，但审核方和分发渠道看到的并不是「一个网页」，而是一个独立应用。缓存、外链、权限、内容一致性这四件事，恰好是壳与内容之间最容易脱节的地方，也是被拒、被下架、被提示风险的常见来源。
下面按实际排查顺序展开，每一项都给出可操作的检查点。
一、缓存：别让用户看到上一个版本
WebView 默认会缓存静态资源，这在纯网页场景里是优点，在 App 场景里却容易变成事故。典型表现是：后端已经发版，用户打开 App 还是旧页面；或者新旧资源混用，页面样式错乱、接口报错。
- 版本与缓存绑定：在资源 URL 上带构建版本号或哈希，发版即换地址，避免依赖手动清缓存。
- 区分缓存层级：HTML 入口建议不强缓存，JS/CSS/图片可以长缓存加指纹。不要一刀切全关，否则首屏体验和流量成本都会变差。
- 提供兜底出口：在设置页或关于页保留「清除缓存并重启」入口，出问题时用户能自救，减少客服压力。
- 注意离线包：如果用了本地离线包方案，要保证包内资源与线上接口版本匹配，并设计好回滚逻辑。
缓存问题本身很少直接导致拒审，但「打开是白屏」「内容与描述不符」这类现象会被审核人员当作功能缺陷处理。
二、外链：跳出去容易，说清楚难
H5 应用天然会跳转。问题在于，审核方关心的是这个 App 到底提供什么内容，而不是它能把用户带到哪里去。
- 把核心功能放在自有域名下，避免首屏或主流程直接跳到第三方站点。
- 外部链接尽量收敛到白名单，并在应用内说明跳转目的，例如「前往帮助中心」。
- 不要在 WebView 里直接加载支付、下载 APK、诱导分享类页面，这类跳转在审核中敏感度很高。
- 检查
target=_blank和自定义 scheme 的处理，避免点击后无响应或跳到系统浏览器造成体验断裂。
如果业务确实依赖多个外部站点，建议在应用内做一层中转说明页，让用户知道即将离开当前服务，这既是体验设计，也能在审核沟通时提供解释依据。
三、权限申请：WebView 不该要的别要
H5 封装 App 常见的错误，是把网页端能调用的能力全部在原生层申请一遍。相机、定位、存储、通讯录一次性弹出来，用户第一反应是警惕，审核方也会追问必要性。
- 先盘点 H5 实际调用了哪些浏览器能力，只对真正用到的能力申请原生权限。
- 权限申请放在具体功能触发时，而不是启动即弹窗。
- 被拒绝后要有降级路径，例如手动输入地址代替定位，上传图片代替拍照。
- Android 侧注意存储权限的替代方案，优先使用应用私有目录和系统选择器。
权限相关的上架与报毒问题，站内已有专门梳理，可参考 应用合规与上架支持 中的排查思路。核心原则只有一条：申请即使用，不用即不申请。
四、壳与内容一致性：审核看的是「你是不是你说的那个 App」
这是最容易被忽略、也最影响结果的一项。应用名称、图标、截图、描述与实际打开后的内容必须对得上。常见的不一致包括：
- 商店描述写的是工具，打开却是一个资讯聚合页；
- 截图展示的是登录后的功能，审核人员拿不到账号；
- 首屏是活动页或下载引导页，主功能藏在二级页面之后。
处理方式很直接：首屏即主功能；需要登录的，在审核备注里提供可用测试账号；活动页和运营位不要占据启动后的第一屏；应用内不要出现与商店描述冲突的引导文案。
另外，壳版本号与 H5 内容版本要能对应。出现问题时，能说清楚「用户当前看到的是哪个版本」，排查效率会高很多。分发环节的稳定性保障，可参考 分发与安装支持 的相关说明。
上线前的自查清单
- 发版后强制刷新入口页，确认无旧缓存残留；
- 外链白名单已收敛，主流程不跳出应用；
- 权限申请与功能触发一一对应，且有降级方案；
- 商店素材、描述与实际内容一致，测试账号可用；
- 保留清缓存与反馈入口，便于收集线上问题。
H5 封装成 App 不是技术难题，难的是把网页思维切换成应用思维。把上面四类问题在上架前收敛掉，审核和分发的阻力会小很多。