小程序 web-view 和 H5 如何通信？有哪些限制和安全注意点？

简化版

小程序可以用 web-view 承载 H5 页面，H5 可通过微信 JS-SDK 或 postMessage 等能力与小程序通信，但通信能力、触发时机和页面跳转受平台限制。安全上要校验 H5 域名、登录态、参数来源，不能把敏感密钥放在 H5 或小程序前端。

详细版

常见场景：

复用已有活动页、协议页、营销页。
承载复杂富文本或 Web 生态能力。
小程序和 H5 之间传递登录态、业务 id、支付结果等信息。

常见限制：

web-view 域名需要配置业务域名。
H5 页面运行在 Web 环境，小程序页面运行在小程序环境。
通信不是任意双向实时调用，要遵守平台提供的接口和时机。
H5 中的 token、参数都可能被观察，后端必须校验权限。

面试回答要强调：web-view 是小程序和 Web 的桥，不是把小程序变成浏览器。

完整版教学

一、web-view 解决的是复用 H5 的需求

很多团队已有 H5 活动页、协议页、帮助中心、富文本页面。如果全部重写成小程序成本高，就会用 web-view 在小程序中承载。

<web-view src="{{url}}"></web-view>

它的价值是复用 Web 内容，但它也引入了双环境问题：H5 有浏览器运行模型，小程序有自己的页面栈、API 和权限模型。两边不是同一个 JS 上下文。

面试回答要先说清楚定位：web-view 适合承载已有 Web 页面，不适合把所有核心小程序能力都塞进 H5 逃避小程序限制。

二、业务域名和 HTTPS 是第一道门槛

小程序的 web-view 不能随意打开任意网址。生产环境通常要求配置业务域名，并满足 HTTPS 等平台要求。

小程序 web-view
  -> 校验业务域名
  -> 加载 H5 页面
  -> H5 再按 Web 规则请求后端

本地调试可能能打开，线上失败常见原因是域名没配置、证书链不完整、重定向到了未配置域名、H5 引入资源域名不合规。

如果活动页主域名是 m.example.com，但登录后跳到 login.example.net，小程序业务域名只配了前者，线上就可能出现白屏或加载失败。域名链路必须完整检查。

三、小程序和 H5 通信要区分方向

小程序给 H5 传参，最常见是通过 URL query 或 hash。H5 给小程序传消息，则依赖平台提供的桥能力或 postMessage 机制，且通常有触发时机限制。

// 小程序侧生成 web-view URL
const url = `https://m.example.com/coupon?id=${id}&scene=${scene}`
this.setData({ url })

小程序 -> H5：URL 参数、登录票据、场景值
H5 -> 小程序：postMessage、跳转小程序页面、JS-SDK 能力

不要把长期 token 明文拼在 URL 上。URL 会出现在日志、分享链路、浏览器历史或错误上报里。更稳妥的是传短期 ticket，让 H5 后端换取会话。

四、登录态要做短期票据和服务端校验

小程序与 H5 常见需求是共享登录态。最危险的做法是把小程序 token 直接拼到 H5 URL 上，让 H5 长期持有。

推荐：
小程序请求后端生成短期 ticket
  -> web-view URL 携带 ticket
  -> H5 后端校验 ticket
  -> 换取 H5 会话

假设 ticket 有效期 60 秒，且只能使用一次，即使被日志记录，攻击窗口也很小。相比之下，一个 7 天有效 token 一旦泄露，风险大得多。

后端还应校验 ticket 和用户、业务场景、来源域名之间的关系。不能只因为 URL 里有 userId=123 就相信当前用户是 123。

易错点：跨环境传参越方便，越要短期化、一次性和服务端校验。前端参数只用于表达意图，不是信任凭证。

五、页面栈、导航和返回体验要单独设计

web-view 页面里的 H5 导航和小程序页面栈不是一回事。用户在 H5 内点了 5 层页面，再按小程序返回，体验可能和原生小程序页面不同。

场景	风险	建议
H5 内多级跳转	返回行为不清晰	H5 自己维护返回或减少层级
H5 跳小程序页	参数和登录态丢失	统一桥协议
分享 H5 页面	场景参数复杂	明确分享落点
支付后返回	状态同步延迟	后端订单状态为准

例如支付场景中，H5 显示“支付成功”不能作为最终结果。小程序页面返回后应查询后端订单状态，避免 H5 回调丢失或被伪造。

六、安全边界：域名、参数、脚本和权限

web-view 把 Web 安全问题带进了小程序。H5 仍要防 XSS、CSRF、开放重定向、token 泄露和第三方脚本污染。

安全检查清单：
1. 业务域名是否可信
2. URL 参数是否签名或短期化
3. H5 是否有 XSS 防护
4. 登录态是否由后端换取
5. 跳转目标是否白名单
6. 支付和权限是否服务端确认

如果 H5 页面允许通过 query 指定跳转地址，例如 redirect=https://evil.com，就可能形成开放重定向。用户以为还在业务链路中，实际被带到外部页面。

小程序前端、H5 前端都不能放 AppSecret、支付密钥、私钥。所有关键签名和权限校验都应在服务端完成。

七、常见误区与追问

误区：web-view 可以加载任何 H5。 生产环境通常需要配置业务域名，并满足 HTTPS 和平台规则。
误区：小程序 token 直接拼 URL 最简单。 URL 容易泄露，应使用短期 ticket 并由服务端换会话。
误区：H5 支付成功页面就是最终状态。 最终状态要以后端订单查询或支付回调校验为准。
追问：小程序和 H5 为什么不能直接共享 JS 上下文？ 它们运行在不同环境和页面模型中，需要通过平台桥能力通信。
追问：web-view 白屏怎么排查？ 查业务域名、HTTPS 证书、重定向域名、H5 控制台错误和网络资源加载。
追问：如何设计 H5 跳回小程序？ 定义统一桥协议，参数短期化，跳转后由小程序查询后端确认业务状态。

八、加强记忆

web-view 题记成“一个桥，两个环境，三道校验”：桥是承载 H5；两个环境是小程序和 Web；三道校验是域名校验、登录票据校验、业务状态服务端校验。它能复用 H5，但不能放松安全和体验设计。

简化版

详细版