小程序搭载HTML，开发要注意这几点

上个月接了个私活，帮朋友改小程序，他之前找刚毕业的学生做的，用了小程序搭载HTML的方案，本来想着一套代码多端复用能省成本，结果上线之后一堆bug，改到最后差点赶不上上线时间，亏了不少尾款。说真的，这两年这种需求越来越多，本来HTML开发门槛低，很多现成的页面直接就能搬进去用，谁知道坑比想象中多得多。

小程序搭载html的适配坑要提前避

我当时打开朋友的项目一看哦，好家伙，直接把之前做的PC端官网HTML打包塞到web-view里了，连viewport meta标签都没改对。你想啊，小程序都是跑在手机上的，不同机型的屏幕尺寸、安全区域都不一样，你不做适配，刘海屏或者灵动岛的机型，底部操作栏直接被吞掉一半，用户点都点不到，这不扯吗？还有滚动冲突的问题，HTML自己有滚动条，小程序页面也有滚动，很多人没处理好，结果滚动着就卡住了，往上滑不动往下也滑不动，体验差到极点。还有就是双击缩放，很多HTML默认允许用户缩放，但是小程序里不需要啊，用户不小心双击放大了，半天回不去，直接就退出去了，这些小问题，改起来不难，但提前没想到，上线了再改，还要重新提交审核，耽误好几天时间。

资源加载的性能问题别大意

很多人觉得不就是嵌个HTML吗？有什么性能好担心的？其实坑真不少。首先就是域名白名单，小程序不管是嵌web-view还是加载HTML里的外部资源，所有域名都得加到小程序的白名单里，少加一个，那张图片那个JS就加载不出来，页面直接缺一块。我之前就见过有人，测试的时候用的是测试域名，上线忘了换生产域名加白名单，结果上线之后整个页面空白，急得团团转，改完加白名单还要等小程序更新，折腾大半天。还有缓存问题，小程序本身有自己的缓存机制，HTML页面也有缓存，两个加起来，有时候你更新了HTML内容，用户打开还是旧的，你说用户会不会觉得你没更新？还有就是资源体积，别把什么乱七八糟的JS都塞进去，一个HTML带好几兆的资源，小程序加载半天出不来，用户早就走了，真的，加载超过三秒，一半用户都会直接关掉，这个说法我想做开发的都不会反对吧。

原生能力对接的坑要留心

你要是只是嵌个静态展示的HTML也就算了，要是需要调用小程序的原生能力，比如扫码、支付、获取用户信息，那坑就更多了。HTML在web-view里是不能直接调用小程序原生接口的，必须要在小程序端写中转代码，通过postMessage传递消息，很多新手不知道，上来就直接调，调了半天没反应，还以为是接口坏了。还有授权的问题，比如你要获取用户的位置信息，H5自己拿不到，必须小程序先授权拿到，再传给HTML页面，少了这一步，你位置信息永远是空的。还有支付，很多人图省事，直接把H5支付嵌进去，结果小程序根本不允许用H5支付，必须用小程序官方的支付接口，你这么搞，审核直接被打回，还可能被判定违规，得不偿失。对了，还有分享，HTML里的分享逻辑和小程序的分享逻辑不一样，你要是没对接对，用户分享出去打开的都是错的页面，白瞎了引流的机会。

审核合规的问题提前排查

小程序审核有多严，做过的都懂，你嵌HTML最容易踩合规的坑。首先就是外部链接，HTML里要是有跳转到外部站点的链接，必须要把对应的域名配置成业务域名，不然根本跳不出去，审核也过不了。还有就是动态加载的内容，很多人把违规内容放在动态加载里，想着审核的时候不显示，上线再打开，别做梦了，现在审核都能检测到动态内容，抓到就是直接驳回，严重的还会封禁小程序。还有内容合规，你的HTML里要是有不符合小程序规范的内容，比如敏感信息、违规导流，哪怕你是无意中带进去的，都会影响审核，我建议上线之前自己先拿官方的审核工具扫一遍，别心存侥幸。还有就是备案的问题，你的HTML对应的服务器域名要是没备案，国内的小程序根本不让用，具体规则以服务商或官方页面说明为准，别搞错了。

调试的时候别只测模拟器

很多开发者图省事，开发的时候只在开发者工具的模拟器里测，觉得没问题就上线了，结果真机一打开一堆问题。不同品牌的手机，微信版本不一样，对web-view的兼容也不一样，我之前就遇到过，安卓手机打开没问题，苹果手机打开HTML页面直接白屏，查了半天才发现是某个CSS属性不兼容，模拟器里根本测不出来。还有就是网络环境，模拟器用的是电脑的网，你用4G或者弱网测一下，加载慢的问题马上就出来了，别等上线了用户说卡你才发现，那时候再优化，花的功夫比提前做多好几倍。

其实话说回来，小程序搭载HTML本身真的是个好方案，尤其是对那些已经有H5站点，想快速做个小程序引流的团队来说，能省掉一大笔重复开发的成本，说白了就是灵活。只要你提前把这些坑都想到，开发的时候多测两遍，别拿到代码就往上堆，大部分问题都能避免。真的，开发这行，很多时候不是技术不行，就是细节没注意，提前避坑比什么都强，省下来的时间喝杯奶茶不好吗？