3 個月前，微信小程序推出了 web-view 組件引發了一波小高潮，筆者所在的大前端團隊寫過一篇淺析，詳情可見：淺談微信小程序前端生態。
我們曾大膽猜想，這一功能，可能直接導致小程序數量增長迎來一波高峰。
畢竟磨刀霍霍卻一直資源不足的團隊應該不少，現在可以把已有 H5 應用嵌入到小程序 web-view 容器中，以最低的開發成本坐蹭微信流量紅利，何樂而不為呢？
我們也曾暢想也許「小程序頁面+ web 頁」混合開發（甚至 web 更重）會成為以後的新趨勢。
2M 代碼限制（如今已更新至 4M）使得像「轉轉官方」這樣功能繁複的小程序必須考慮引入 web 內容，再有就是小程序審核發布機制使得它終究不能像 web 一樣迭代迅速。
正好筆者所在的業務線，存在已有的 H5 應用卻無對應小程序的情況。我們在開發對應小程序時也算收穫了不少經驗（踩了不少坑），分享給有小程序需求的朋友們~
最大的坑：不支持服務通知
是的，web-view 不支持推送服務通知（或稱模板消息)。
如圖所示，類似訂閱號在對話列表的模式
為什麼能稱為最大的坑？我們先了解一下服務通知，以下引用全部來自微信官方小程序文檔。
基於微信的通知渠道，我們為開發者提供了可以高效觸達用戶的模板消息能力，以便實現服務閉環並提供更佳的體驗。
看起來很厲害，如果咱們的小程序沒這個功能會怎樣？
「用完即走」是小程序的口號，沒有服務通知代表失去了高效觸達（召回）用戶的能力，然後用戶就再也回不來了，促活和留存怎麼辦？
很多功能不是像訂閱號裡看篇文章一樣，幾分鐘就能搞定的，比如絕大部分電商的行為：從搜索、瀏覽比價、跟賣家交流，到加入購物車僅僅是走完了不到一半的生命周期；然後才是下單支付評價，還不包括推薦復購取消退款等等，沒個15-30分鐘哪裡夠。然而，沒有用戶會一直開著某個小程序，別人還要切出去聊天刷朋友圈呢。沒有了化同步為異步的能力，絕大部分產品邏輯如何實現服務閉環？
一篇教你突破小程序模板消息推送限制的文章中，也總結了服務通知的「多、快、好、省」等特點。這些先不展開，我們還能看到：
該小程序近 30 天訪問來源數據顯示，有 20% 左右的用戶通過模板消息進入小打卡，在各種來源中排名第 3 位（如果分母去掉新用戶的來源，比率和排名會更高）；
況且，用戶基本都不會關閉微信的消息推送，相較 App 的推送和簡訊推送來說，小程序的推送觸達率會高很多。
so，沒有哪個（正經的）小程序會不支持服務通知（流氓些的比如拼多多，看了個商品能給你連著推 N 條）。試想一下沒有推送通知的 APP，你的產品、運營和老闆們會同意麼？
為什麼不支持
然而，為什麼 web-view 不支持服務通知？哪裡坑了？還請繼續看微信官方文檔裡的定義。
下發條件：用戶本人在微信體系內與頁面有交互行為後觸發
總結起來就是，支付3條、提交表單（該表單需聲明為要發模板消息）1條，7天有效。
首先，這裡區別了支付和提交表單兩種行為，要分不同的情況上報，開始了看到沒…
然後，web-view 不支持支付能力（其 JSAPI 能力不包含微信支付），這個在微信的文檔裡沒有顯式的聲明，不過能在微信的 web-view 問題匯總中看到，這個也挺坑的…
其實，支付行為對小程序本身而言只是極少數的交互，大多數小程序甚至不含支付。所以我們基本還得靠表單，可問題就出在這：小程序的 web-view 和表單（form 組件） 不兼容！！！
PS：我們先區分下 form 組件，它跟 web-view 內網頁的表單（form 標籤）沒有任何關係。
PS：RN 和 Weex 也沒有 form 組件。為什麼筆者一看到 form 就想到如下的圖？
1999年12月發布的 HTML 4.01 Specification 就支持了 form，自 AJAX 在2005年風靡世界後，跨域、文件上傳都有了 form 之外的解決方案，誰沒事還用這玩意？
先不吐槽微信文檔裡 form 組件的定義是有多簡陋，再看其 web-view 組件的定義~
web-view 組件是一個可以用來承載網頁的容器，會自動鋪滿整個小程序頁面。
何止鋪滿，嘗試把 web-view 放在 form 組件內，form 組件都鋪沒了。so，自動鋪滿 = 頁面獨佔 = 所有其他元素都被直接覆蓋…好吧，別人在文檔最下方的 Bug & Tip 裡寫了行小字~
綜上，web-view 跟服務通知已絕緣。so，小程序裡網頁的交互行為不算在微信體系內！！？
我不禁回想起 Google 之前推出的 PWA（Progressive Web App），在這又有那麼一絲神似。
兩者同是基於 Web 的技術，開發出（或許）可替代 APP 的偽原生應用；
PWA 的推送通知因其 API 太超前和一些不知名的服務被和諧用不了（你懂的）；
小程序的服務通知嘛，你要想用 web-view 做殼就發布上線也用不了。
扯遠了點，但大家都說：PWA 是引領下一代潮流的 Web 技術超集，而小程序是對 Web 技術進行修（閹割）補（Hack）的（黑）魔法…
不做展開，歡迎移步：如何客觀地評價「小程序」的體驗? Web 在繼續離我們遠去
那怎麼辦？由於筆者團隊的業務對服務通知與支付有大量依賴，那麼我們就要徹底放棄 web-view，把之前的 H5 應用全部重寫至原生小程序了麼？顯然不是。
正如前文所說，支付僅是電商諸多環節中的一環，主要在商品 or 訂單詳情頁（這些必須重寫）。關於服務通知，通過幾個重寫後的原生小程序頁，也能收集到足夠的 form。
基於 wepy，模板部分就是個替換+適配的活，JS 麻煩些。離同構差距不小，美團您的 mpVue 呢？
剩下的業務，理論上都可以用 web-view 來實現！！！運營活動頁就不說了，開放 web-view 能力最大的優勢就是方便了這類需求。小程序首頁，甚至配置了 tabBar 的小程序頁都可以。因為我們還發現一個神奇的 feature…
大概是用了原生的 UITabBar，web-view 和 tabBar 能共存
虧了 web-view 組件的及時推出，我們只需重寫部分詳情頁和其依賴的組件，最後復盤一下。
定位：小程序的 web-view 就像是 Hybrid 客戶端嵌 H5 頁一樣，需要一些基礎能力的時候，比如支付、服務通知（IM 和召回等場景）等等，最好使用原生小程序；
兼容性：這個無須過多擔心，最新的基礎庫統計數據，1.6.4+ 的覆蓋率已達 95% 以上；
數據通信：小程序 => web-view 可以在 url 中用 search、hash 的方式，web-view => 小程序可用 bindmessage，一般用來解決分享信息傳遞的問題；
登錄：a. web-view 內走微信授權，b. 小程序登錄後再進入 web-view，並把相關 cookie 通過 url 傳遞給 web-view。
其它 feature（歡迎討論和補充）：
web-view 跟小程序是獨立的兩個環境，數據完全不通，包括 cookie、session、localStorage 等等；
但小程序內嵌 web-view 跟微信內置瀏覽器是一套環境，也就是說你在 web-view 裡面留下的以上痕跡，到微信裡內置瀏覽器打開也有；
在兩種環境下，不太容易區分到底是什麼環境，小程序官方給的判斷方法是 window.__wxjs_environment === 'miniprogram'，但是在 web-view 進入第二頁時候，安卓機下這個變量就 undefined 了。
其它的坑（常見錯誤）：
打開的域名沒有在小程序管理後臺設置業務域名(注意是業務域名，不是伺服器域名)；
打開的頁面 302 過去的地址也必須設置過業務域名；
頁面可以包含 iframe，但是 iframe 的地址必須為業務域名；
打開的頁面必須為 https 服務；
開發者自己檢查自己的 https 服務是否正常，測試方法：普通瀏覽器打開對應的地址； 等等，詳情請移步 web-view 問題匯總(https://developers.weixin.qq.com/blogdetail?action=get_post_info&lang=zh_CN&token=585555149&docid=ebfd9e5ec9986b4f23c41f8d8bbf2730)查閱，或在該帖子裡留言。