web-view 适合做什么

很多团队本来就有一套成熟的 H5 业务，不想在小程序里重写一遍。小程序的 web-view 组件就能把一个网页直接嵌进小程序里，让老 H5 快速获得小程序的入口和流量。

但 web-view 不是万能的。它适合内容型、营销型的页面，比如活动页、帮助中心、富文本详情；不适合对性能要求极高、要频繁调用原生能力的核心流程。核心交易还是用原生页面做，web-view 做补充。

一个常见的误区是「既然能嵌网页，干脆整个小程序都用 H5 写」。那样做出来的东西又慢又卡，还调不动多少原生能力，用户体验很差。正确的姿势是：外壳和主流程走原生，把已经成熟、更新频繁、对性能不敏感的页面用 web-view 嵌进来，两边各取所长。

还有一点要注意，web-view 里的网页是跑在微信提供的浏览器内核里，不是你自己 App 的 WebView，所以有些浏览器特性不一定支持，做 H5 的时候要按小程序的内核环境来调试。

本文核心知识点
  • 嵌入一行标签加载 H5。
  • 通信postMessage 双向传数据。
  • 登录态H5 和小程序共享用户身份。
  • 取舍哪些页面该嵌、哪些该原生。
小程序 web-view 融合示意：蓝调渐变背景上两块互相连接的屏幕面板与流动数据线的扁平科技插画
原生壳子套着 H5，靠 postMessage 把两边的数据接起来。

内嵌一个 H5 页面

用 web-view 嵌网页很简单：给它一个 src，指向你的 H5 地址就行。但这个域名必须先在小程序后台的业务域名里配好并校验，否则打不开。

<web-view src="https://你的域名/h5/page"></web-view>

业务域名要走 HTTPS，并且完成校验文件上传。配好之后，同一个 web-view 会占满整屏，自带导航栏返回。

另外，web-view 一个页面一般只放一个，别在一个页面里塞好几个，那样既卡又难管。如果一个流程里有好几步 H5，就在 H5 内部自己做页面跳转，小程序这边只开一个壳。

H5 与原生互传数据

嵌进来只是第一步，真正有用的是两边能对话。H5 里引入小程序的 JSSDK，就能用 postMessage 给小程序发消息；小程序这边监听事件接收。

方向做法
H5 → 小程序wx.miniProgram.postMessage
小程序 → H5拼在 src 的查询参数里
跳转原生页wx.miniProgram.navigateTo

要注意：H5 发的 postMessage 不是实时到的，一般在特定时机才触发回调。所以别把它当高频通道，关键数据走查询参数和接口更稳。

反过来，小程序要通知 H5 做什么，最省事的方式是改 src 重新加载一次，把新参数带过去。虽然简单粗暴，但胜在可靠。真要做无刷新通信，就得靠 JSSDK 的事件来回绕，复杂度一下就上去了，没必要时别追求。

登录态与跳转衔接

H5 里也要知道当前用户是谁。常见做法是小程序拿到登录态后，把 token 拼在 src 后面传给 H5，H5 用这个 token 请求自己的接口。

  • 登录态通过 URL 参数传入，别写死。
  • token 要有时效，过期了要能续。
  • 敏感参数别明文长期挂在地址栏。

用户在 H5 里登出或者 token 过期了，要能通知小程序这边重新走一次登录，别让他卡在一个没权限的页面里反复点。登录态的续期和失效，两边要约定好。

性能与体验取舍

web-view 里的 H5 是网页，加载速度、滑动流畅度都不如原生。图片多、脚本重的 H5 在低端机上会卡。所以嵌进去的页面要做性能优化，别直接把臃肿的活动页原样塞进来。

web-view 是拿来快速复用的，不是拿来堆复杂逻辑的。

上线前一定要在低端机上实测一遍。web-view 里 H5 的加载时间、滑动跟手程度，在老手机上和真机调试时差别很大。发现卡就先砍图片、压脚本、首屏只加载必要内容。把嵌进来的 H5 当成一个正式页面来优化，而不是随便塞进来就算了。

做完这些，web-view 就成了一个好用的补充渠道：老业务快速上线，主流程保持原生体验，两边都不耽误日常使用和后续的快速迭代与日常的维护工作。