先明确一件事：审核看的是“用户看到什么”，不是“你怎么实现的”
H5 封装成 App 通常用 WebView 承载页面，技术上完全可行，但审核方关注的是用户实际体验：打开后是否有可用的内容、权限申请是否与功能对应、页面跳转是否仍在应用边界内。壳只是容器，内容才是被评估的对象。把下面四类问题在提审前自查一遍，能减少大部分反复沟通。
一、缓存：别让旧页面成为“内容不一致”的证据
WebView 默认会缓存静态资源，这在分发后更新页面时容易出问题：服务端已经改了，用户端还在展示旧版本，审核人员看到的和你描述的版本对不上。建议：
- 对入口页和关键页面设置合理的缓存策略，HTML 走协商缓存，静态资源用带 hash 的文件名。
- 发版时同步更新壳内的版本号，并在页面里提供可感知的版本标识，便于排查。
- 避免在壳里硬编码大量业务文案，文案放服务端，减少“壳更新才能改字”的耦合。
- 首次启动的离线兜底页要能说明当前状态，不要出现长时间白屏。
缓存问题本质是发布节奏问题。把壳版本与 H5 版本分开管理，能避免“改了一个字要重新提审”的被动局面。
二、外链：跳出去容易，说清楚难
审核对外链的敏感点在于：用户是否知道自己离开了应用、跳转目标是否与申报内容相关、是否存在诱导下载或支付。实践中的做法：
- 站内可完成的流程不要用外链，尤其是注册、支付、客服等核心路径。
- 必须外跳时，用系统浏览器打开并给出明确提示，不要用无地址栏的 WebView 伪装成站内页面。
- 外链域名保持稳定，避免频繁更换导致审核时无法访问；域名稳定性可参考分发与域名相关服务的说明。
- 不要在 H5 里引导用户下载其他安装包，这类行为在多数市场都属于高风险项。
另外，壳内拦截 URL 时要留日志，出现“点了没反应”的情况能快速定位是拦截规则写错还是目标页不可达。
三、权限申请：WebView 不会替你解释理由
H5 页面调用摄像头、定位、存储时，最终都要落到原生权限上。常见问题是页面一打开就弹权限，用户不知道为什么要给。建议按需申请：
- 权限在用户触发对应功能时再申请，并配一句说明用途的文案。
- 壳里声明的权限要与实际调用的能力一致，声明了却不用，或者用了却没声明，都会在审核或分发环节被质疑。
- H5 侧的 getUserMedia、geolocation 等调用要在壳里做桥接和降级处理，用户拒绝后页面不能卡死。
- 上架前用工具核对最终合并后的权限清单，第三方 SDK 带入的权限同样算在应用头上。
权限清单是审核和分发平台都会看的第一手材料，保持“声明即使用”比事后解释更省事。
四、壳与内容一致性：这是最容易被判“货不对板”的地方
壳与内容不一致通常表现为：应用名称、图标、截图与实际打开后的页面风格差距过大；申报为工具类，打开却是资讯流；或者首屏是原生页面，深层全是 H5，体验割裂。处理思路：
- 商店素材使用真实运行截图，不要用设计稿替代。
- 应用描述里如实说明内容来源和主要功能，避免用模糊词覆盖多个品类。
- 首屏加载要有明确的品牌与功能入口，减少“打开像浏览器”的观感。
- 如果内容由服务端下发，确保审核期间可访问、可交互，不要出现登录墙后一片空白。
分发渠道方面，不同市场对 WebView 类应用的关注点略有差异，但共同点是：能说清楚“这个应用解决什么问题”。涉及多渠道上架时，可参考应用分发相关服务了解包体与渠道管理的基本做法。
提审前的自查清单
- 断网、弱网下首屏是否有可理解的提示。
- 核心流程是否全部在应用内完成，外链是否有明确提示。
- 权限是否按需申请，拒绝后功能是否可降级。
- 商店素材与真实界面是否一致，描述是否与实际功能对应。
- 壳版本号与 H5 版本号是否可追溯。
把这五项做成固定检查项，比每次提审前临时排查更可靠。H5 封装本身不是问题，问题通常出在“用户看到的”和“你申报的”之间的差距上。