小程序不能使用各种浏览器暴露出来的 DOM API，进行 DOM 选中和操作
原因：在小程序中，渲染层和逻辑层是分开的，分别运行在不同的线程中，逻辑层运行在 JSCore 中，并没有一个完整浏览器对象，因而缺少相关的DOM API和BOM API。
为什么要这样设计？
因为JavaScript是可操纵DOM的，如果JavaScript线程和UI线程同时运行，即在修改这些元素属性同时渲染界面，那么渲染线程前后获得的元素数据就可能不一致，导致传统web开发渲染线程和脚本线程是互斥的。于是当JavaScript引擎执行时GUI线程会被挂起，GUI更新会被保存在一个队列中等到引擎线程空闲时立即被执行。 因此长时间的脚本运行可能会导致页面失去响应。
小程序DOM操作API —— SelectQuery
浏览器中：
const demo= document.querySelector('#demo')
console.log(demo.boundingClientRect().top)
小程序中：
const query = wx.createSelectorQuery()
// 组件中：const query = wx.createSelectorQuery().in('组件id')
query.select('#demo').boundingClientRect()
query.exec(function (res) {
console.log(res[0].top)
})
可以发现有三点明显的区别：
- 通过createSelectorQuery创建了一个query对象而不是document.querySelector
- 在query对象上执行查询操作并非马上执行，而是进入等待队列，直至query对象上exec被调用才触发查询行为
- 查询结果是异步返回的，在callback中按查询顺序依次从参数中读取
第一点区别产生的原因是首先小程序双线程模型决定了业务代码中不能拿到document对象， 也就无法在上面调用相关查询方法。那为什么要通过调用createSelectorQuery()返回查询对象而不是把查询对象定义为全局的呢？这是因为小程序每个页面的视图层都对应一个webview，而所有的页面都共用一个逻辑线程，这种一对多的关系在通讯时需要有id来进行区分，所以每次createSelectorQuery时返回的query对象是绑定了当前视图层webview对应id的。
第二、三点的查询非立即执行，而是在exec被调用时真正触发比较好理解：业务代码在逻辑线程，真实dom在另一个webview线程，线程间的通讯需要借助宿主能力完成，query对象的exec方法被触发时小程序把callbak存储起来，然后调用native宿主暴露的方法去通讯，拿到webview线程查询回来的结果之后进行反序列化处理，传递给先前保存的callbak并开始执行，所以这里是异步的。