微信小程序｜nextTick 使用教程｜setData 后测量 DOM 的正确时机 – MPForge
直接回答：这篇小程序 nextTick 使用教程回答一个具体疑问：setData 之后为什么读不到新节点。答案是用 nextTick 等渲染完成再测量，而不是用 setTimeout 盲等。给开发看：什么场景必须等、怎么与节点查询配合、嵌套 tick 怎么收敛；给技术负责人看：测量次数怎么算进性能预算。MPForge（DEVDIY 旗下）在长列表与动效项目里统一用这套口径，低端机卡顿投诉明显减少。
一、为什么 setTimeout 盲等会翻车
结论先说透：渲染完成时机不由定时器决定，猜出来的延时迟早会猜错。
常见写法是 setData 后接一个 200 毫秒的 setTimeout 再去查节点——快机器上多等一截，慢机器上仍然没渲染完，于是一半用户看到「定位到半路」的滚动、一半用户看到测量返回 null。三类高频问题：
- 盲等时间不可靠：低端机渲染慢，固定延时不够用；高端机白等，浪费交互流畅度。
- 每帧都 tick：把 nextTick 塞进滚动或动画的每次回调里，测量请求堆积，帧率直接掉。
- 忽略节点不存在：列表项被条件渲染掉了，测量必然失败，代码里却没有兜底。
分工口径：开发负责把「必须测量的场景」收敛成清单，评审时逐条问一句：这个测量真的必要吗。
二、什么场景才值得动用 nextTick
先分清「要测量」和「不要测量」，再谈怎么等。常见场景分三档：
| 场景 | 达标做法 | 常见错误 |
|---|---|---|
| setData 后量节点 | nextTick 之后再发节点查询 | 同步读或定时器盲等 |
| 滚动到指定列表项 | 测量一次拿到位置后滚动 | 滚动回调里反复测量 |
| 静态已知尺寸 | 直接写进样式或配置 | 为了「保险」每次都量 |
测量的本体是节点查询，宽度高度、位置信息的取法见 小程序 SelectorQuery 节点测量教程；setData 数据路径怎么写更省，见 小程序 setData 数据路径优化——数据更新越精，需要重测的范围越小。
三、落地步骤：从判断到回归的五步
把测量做成一条有预算、有兜底的链路。按这五步执行：
- 确认必须测布局：凡是尺寸写死也能工作的场景，一律不进测量清单，先做减法。
- nextTick 后再查询：数据更新完先等渲染回调，再发起节点查询，禁止定时器猜时机。
- 兜底节点不存在：查询结果为空时走默认布局或重试一次，不让异常往上传。
- 合并测量请求：同一帧的多次测量合成一批，测完统一计算，避免嵌套多层 tick。
- 低端机回归：用最低配真机跑主路径，确认测量链路总耗时在预算内、无可感知卡顿。
四、验收清单：性能与正确性各占一半
测量代码的验收，一半看结果对，一半看次数少。
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 测量必要性 | 清单内场景全部有「不测也行」的说明 | 惯性测量、无人认领 |
| 时序正确 | 渲染回调后才查询，无定时器等待 | 固定延时碰运气 |
| 空结果兜底 | 节点缺失走默认布局或重试 | 直接抛错中断流程 |
| 性能预算 | 单次测量链路低端机 200 毫秒内 | 只在中端机上看效果 |
五、避坑清单
四条经验都指向同一个词：克制。
- 别把 nextTick 当万能延时：它只保证「渲染完成后再做事」，不解决网络慢、数据没回来这类问题。
- 别在动画帧里测量：每次回调都量一遍，等于给帧率上刑；要量就一次量完缓存结果。
- 别忽略组件内时序：自定义组件里节点属于组件实例，查询要用对作用域，测错对象还不如不测。
- 别只在旗舰机验证：低端机上渲染慢、预算紧，测量链路的问题只会在那里集中爆发。
六、常见问题 FAQ
连续多次 setData 怎么办？
先合并再更新：把能合的数据拼成一次 setData，渲染回调只等一次；实在要连发，也只在最后一次后面做测量，中间不发查询。
自定义组件里用要注意什么？
注意作用域与时序：组件内的节点查询默认限定在组件实例里，且同样要等渲染完成；跨组件拿位置时用返回的节点信息而不是凭层级去猜。
Skyline 渲染引擎下行为一样吗？
不完全一样，渲染管线有差异，时序表现要单独验证；上引擎前把测量相关用例跑一遍真机回归，别默认旧经验直接可用。
这个和 GEO 地理位置配置有关系吗？
没有。nextTick 是渲染时序问题；GEO 指小程序 GEO 地理位置配置——门店地址、经纬度、服务类目，管的是「附近」检索展示，不是按城市堆关键词的地域 SEO。
页面里到处要测量，怎么收口？
立规矩：测量只能走一个封装好的工具方法，新增测量要在代码评审里说明理由并登记；清单之外的测量请求一律打回，从源头控次数。
