微信小程序的组件web-view推出有一段时间了，这个组件的推出可以说是微信小程序开发的一个重要事件，让微信小程序不会只束缚在微信圈子里了，打开了一个口子，这个口子或许还比较小，但未来有无限可能。
简单思考
1.通过web-view嵌入网页功能开放,给微信小程序的发展带来无限的可能，有好，也有坏，但利大于弊。好处在于让微信的开放性更强，无论将来混合模式和还是纯H5都有更多的机会在微信这个大舞台有表演机会。坏处可能就是也打开了漏洞之门，会有更多鱼龙混杂情况出现，这对微信的生态圈是个挑战。
2.这个口子的打开，再关上的可能性就不大了，而且只能越大越开，按照微信的节奏，微信应该有足够把握才会开放这个功能，一切都在微信的掌控当中。
3.大量基于h5的网站或应用都会被“小程序化”，微信这个“大”浏览器成为移动互联网海量流量的入口。微信搜索会不会成为移动搜索的绝对第一的搜索？
4.对前端工程师这个职业带来巨大的影响，降低了开发小程序的成本，让前端工程师更关注网页的架构，减小微信小程序的总体开发压力。
5.让热部署、热更新更为简单，原来调整小程序风格和布局需要重新审核和发布，这个周期有些长。有了web-view后，基于它开发的页面，可以随时改变外观、布局、数据。
简单实践
1.web-view里内嵌的域名域名在小程序管理后台设置业务域名，注意是业务域名，不是服务器域名。另外个人小程序目前是没有这个设置，因此也就无法使用这个功能。
2.一个页面（wml）只能放置一个web-view，且会覆盖其他的组件铺满屏幕，这时候你就当微信小程序是个浏览器好了。
3.web-view打开的页面必须是支持https的。
4。目前支持的jssdk接口还比较少，只支持“图像接口”,“音频接口”,“智能接口”,“设备信息”,“地理位置”,“摇一摇周边”,“微信扫一扫”,“微信卡券”,“长按识别”，比如获取用户信息，微信支付之类都不行，我猜以后会慢慢放开，逐步达到微信公众号的开放程度。
5.支持iframe ，最开始还不需要域名白名单（业务域名），后来把这个漏洞给补上了，不给人滥用的口子了。如果你页面上有google adsense可以要注意了，如果使用的苹果版微信，用web-veiw打开含有google adsense就会报错（有的安卓偶尔也会报错，原因不明），因为google adsense会虚拟一个iframe出来，google的域名自然不会在你的业务域名里，就会报错。
6.如果你的网站做了302跳转，跳转的域名也要设置在业务域名里，别想着鸡贼，能躲过这个配置。
7.通过内嵌网页的功能可以实现站内链接的跳转，当然不是小程序页面的跳转，而是在小程序里打开网页，虽然感觉上有些别扭，不过总算弥补了无法跳转的麻烦，对资讯类的小程序是很好的功能。
8.通过在onload里的options.url 参数可以解决分享web-view页面加载的问题，不过需要对options.url 通过decodeURIComponent进行解码，因为在分享转发的时候，微信小程序对url的特殊字符进行了十六进制编码，因此需要通过decodeURIComponent来解码，小程序的web-view页面才能正常加载。
9.web-veiw页面有时候无法触发onShareAppMessage方法，原因不明。如果有非web-view的页面和web-view同时存在的小程序，如果是非web-view的页面跳转到web-view页面，在转发web-view页面的时候无法触发onShareAppMessage方法。如果有非web-view的页面和web-view同时存在的小程序，如果是非web-view的页面跳转到web-view页面，在转发web-view页面的时候无法触发onShareAppMessage方法。
10.web-veiw页面 无法使用“打开调试”功能，如果需要看调试，需要返回上一个不使用web-view的页面查看。
11.web-view 嵌入的网页里如果有白名单以外的域名链接，点击后会报错。
12.web-view不支持微信支付，但web-view内嵌的页面使用了公众号授权的微信支付，是可以在内嵌的页面使用微信支付的。换句话说，如果如果用web-view内嵌公众号的h5页面，利用JSSDK是可以使用微信支付的
