微信小程序开发h5 第1篇
1、在h5页面里面需要支付的地方或者方法里面，请求后端接口，拿到支付相关参数。
2、然后调用jssdk的方法
、在小程序端准备一个单独的支付页面，用来接受h5传过来的参数，在小程序的js文件里面的onLoad周期函数里面拿到参数
【小程序端】
1、准备一个单独的页面，用来处理h5支付的逻辑，比如 pages/h5pay/index，这个页面要和h5端跳转的页面保持一致
2、在webview页面的onShow周期函数，获取支付结果，改变url，通知h5支付结果
3、在h5页面的支付结果页面里面，通过url的参数来显示提示结果，或者其他内容
OK，通过以上步骤，就可以完美实现微信小程序内嵌h5调用小程序支付了。
微信小程序开发h5 第2篇
方案很简单，但是实现起来的话细节和坑特别多，下面且听我挑几个关键的 trick 来介绍：
想要在小程序的逻辑层模拟出一个 dom 树，本质上和建立一棵虚拟树类似，因为它并不是真实的 dom 树。整个流程简单来说是这样的：
不管是页面中的静态 html 内容还是使用 innerHTML 等接口动态插入的 html 内容都可以走上面的流程来进行 dom 树的创建。dom 树创建比较简单，只是细节比较多，此处的问题是建立好的 dom 树要如何渲染到视图层呢？上面提到了一个关键点：将 dom 节点转成小程序的自定义组件。
此处再重复一次表强调：小程序的自定义组件支持递归引用！
什么叫递归引用？感觉用文字表达不如直接用代码说明来的快，我们先直接编写一个名为 element 的自定义组件：
看代码应该很容易就能明白，所谓递归引用就是自己可以作为自己的一个子组件使用，这样可以很方便地将 dom 树给渲染在逻辑层，并且也不需要我们为每种节点标签给编写一个自定义组件，如上述例子，只需要编写一个 element 自定义组件基本可以覆盖所有标签。
同样，根据上述例子可以很明显的看出，每个节点只负责渲染自己的子节点，其他如孙子节点等后代节点一概不管，这样就避免了在更新时需要将整棵树结构传递给视图层的麻烦问题。
对于从逻辑层向视图层传递数据，小程序里有个数据包大小的限制，此处若同步整棵树结构，一来可能爆了这个限制，二来会传递很多无用数据，增大更新开销。
创建好 dom 树后，下一步就是要想办法将小程序创建的自定义组件实例和我们创建的 dom 节点给一一联系起来。首先，我们得给每个 dom 节点生成一个节点 id 用于区分，根节点的节点 id 可以在构建过程中直接生成，假定根节点就是 body 节点，那么生成的页面的 wxml 和 json 中大概是这样的：
body 节点同样是用上面例子中的 element 自定义组件来渲染，修改下 element 自定义组件的 js 文件：
如上述代码所述，在自定义组件的 attached 生命周期中即可拿到节点 id，然后根据此节点 id 从 dom 树中找到对应的 dom 节点，两者之间即可建立关系。
找到根节点后，后续节点就好办了。根节点对应的自定义组件实例在和 dom 节点建立联系后，就可以通过 dom 节点拿到子节点列表，进而开始渲染子节点。 由上可知，每个节点只负责渲染自己的子节点，每个节点的渲染流程都和根节点一样：
根据这个逻辑修改一下上述例子中的 element 自定义组件的代码：
如此递归下去，即可将自定义组件实例和 dom 节点一一联系起来，同时将整棵 dom 树渲染出来。
假若逻辑层想要获取视图层的渲染信息，比如调 getComputedStyle 接口获取节点样式、使用 clientWidth 或取节点宽度等，因为逻辑层本身只是模拟了 dom 树，并没有实现布局和渲染的模拟（理论上可以实现，只是开销巨大，而且很难与小程序本身环境的渲染结果对齐），所以这块实现起来很头疼。
目前的方案上使用小程序的 selectorQuery 接口来拉取渲染信息，因为此接口只能异步拉取，所以没法完整模拟渲染信息的即时同步。为了尽可能做到相对同步，在初始渲染完成后尝试拉取一次渲染信息，之后在每次触发节点更新后再异步拉取渲染信息，同时提供一个异步接口给某些需要即时拉取渲染信息的场景中使用。
上面提到小程序的逻辑层是跑在一个 js 线程中，这个 js 线程是一个纯净的 js 线程，别说那些 bom、dom 接口了，连一个正经的全局对象都没有。
小程序中其实有 global 对象，但是和我们熟悉的 nodejs 中的 global 对象实现不一样，所以此处按下不提。
做前端开发的同学们应该都知道，h5 环境中声明在全局的变量/函数会挂在 window 下，在页面的其他地方是可以使用或者是通过 的方式来访问的。在小程序的运行环境中这些是不存在的，那就意味着会有下述这些问题：
这个问题很严重，要知道我们很多时候访问一些对象都会忽略掉 window. 这个前缀，比如使用 location 对象的时候。也就是说，必须对这些 js 做一遍后处理，强制将全局函数挂在 window 下，强制通过使用 的方式访问全局变量/函数。经过后处理后，上述例子会变成下面这样：
嗯，完美解决！
上面提到的是整体的实现框架，也简单的提到几个坑。当然，这只不过是冰山一角，事实上需要兼容的坑、无法按照标准实现的接口和完全无法实现的特性犹如满天星，数都数不清，幸运的是我们并不完全依赖到所有的接口，有些时候我们仅仅需要用到像 querySelector、事件系统、异步请求等接口就可以构造出大部分 h5 页面，而这些大多是能做到兼容的，所以对于某些不太复杂的场景来说还是可行的。
微信小程序开发h5 第3篇
h5 页面是运行在 web 环境下，小程序本身也是基于 web 的，那为什么一直没有办法让 h5 在小程序里直接运行呢？原因在于小程序特有的运行环境。
以一个小程序的页面为例，通常一个小程序的页面至少包含三个文件：wxss 文件、 wxml 文件和 js 文件。其中 wxml 文件和 wxss 文件组成了页面的视图层，js 文件则属于页面的逻辑层，在小程序中，视图层和逻辑层是在不同的线程中执行的。小程序里所有页面的逻辑层都在一个 js 线程中运行，而视图层则分别在不同的 view 线程中。通常一个页面对应一个 view 线程，为了对性能的控制，不会允许用户无节制的启动 view 线程，所以也就有了页面栈数量的限制（目前最多允许打开十层页面）。
在 view 线程中是有类似浏览器一样的环境，但是只有页面的视图层在上面跑，页面的渲染完全基于另一个 js 线程传输过来的数据。js 线程是一个纯净的 js 环境，那些你想要调的 、 等 dom/bom 接口通通都没有，你只能在这里执行 js 代码，调用官方提供的接口，而页面的逻辑层就是在这样的线程中跑。这样问题就出来了，页面会渲染成什么样子，完全基于初始模板和数据，你想调接口来修改页面结构，门都没有～