把现有网站塞进小程序，网站最直接的封装办法是用 web-view 组件加载网页。这不是小程序什么高深技术，微信官方文档里写得清清楚楚，网站但真正动手的封装人才会碰到那些文档没提的坑。

我上个月帮一个做本地生活信息的小程序朋友处理过这事。他的网站网站是五年前找人做的，PC 端和移动端各自一套页面，封装日活大概两三千。小程序想上小程序，网站又不想重写代码。封装我看了眼他的小程序技术栈——PHP 混着 jQuery，页面里嵌了不少第三方统计脚本。网站这种项目重新开发成本太高，封装web-view 确实是小程序唯一可行的路。

域名备案是硬门槛

小程序里的 web-view 不是随便什么网址都能加载的。你得先把域名备案，然后在小程序后台配置业务域名。这个流程走下来，快的话三天，慢的话一周多。朋友那个域名之前只做了 ICP 备案，没有在小程序后台配过，第一次提交就被打回来了，原因是域名没有经过校验。校验文件要放到网站根目录，他服务器是 Windows 的，路径搞了半天才对。

配好之后，web-view 加载页面倒是顺畅。但问题马上来了——页面里的支付按钮点不动。小程序的 web-view 里不能直接调起微信支付，必须走小程序的支付接口。这意味着你得把网站里的支付逻辑改掉，通过 postMessage 和小程序通信。朋友那个网站用的是第三方聚合支付，改起来又是一通折腾。

登录态同步是个麻烦事

网站有自己的用户体系，小程序也有 openid。两边的登录状态怎么打通？常见的做法是：web-view 加载的页面里带上小程序传过去的 token，网站后端验证 token 后返回用户信息。听起来简单，但实际做的时候，token 过期时间、刷新机制、跨域 cookie 这些问题都会冒出来。朋友那个网站用的是 session，小程序这边又没法直接共享，最后改成 JWT 才勉强跑通。

还有页面样式。网站在手机浏览器里看着还行，塞进小程序 web-view 之后，顶部导航栏和底部 tabBar 把可视区域压得很窄。原来一屏能显示的内容，现在得滑动才能看全。朋友那个网站本来移动端适配就一般，这下更挤了。改 CSS 花了两天，主要是调整 padding 和字号。

性能比想象中脆弱

web-view 加载网页，本质上还是靠系统浏览器内核。安卓上用的是 X5 内核，iOS 上是 WKWebView，表现差异不小。朋友那个网站首页图片多，安卓低端机上加载要五六秒，白屏时间太长。后来加了骨架屏，又把图片压缩了一遍，才勉强降到三秒以内。但跟原生小程序页面比，还是慢。

另一个问题是返回手势。iOS 上从屏幕左边缘右滑，有时候会直接退出小程序，而不是返回网页上一页。这个行为跟 web-view 的页面栈管理有关，得在网页里监听 popstate 事件做处理。朋友那个网站没有前端路由，所有跳转都是整页刷新，处理起来反而简单——直接让小程序拦截返回按钮就行。

说到底，网站封装小程序适合那种已经跑通、不想大改的项目。如果网站本身移动端体验就差，封装进去只会更糟。朋友那个项目最后上线了，日活没涨多少，但至少多了一个入口。他跟我说，早知道这么麻烦，当初就该直接做小程序原生页面。这话我听过太多次了。