企业官网建设流程全解析

前言

小程序开发有些坑很隐蔽，官方文档虽然有说明，但容易被忽略。这篇整理几个高频且容易踩的问题，按“事件取值 → 生命周期 → 渲染兼容 → 性能”的顺序排列。

一、data-* 大小写会被静默转换

这是最典型的坑之一。

<viewdata-elementType="image"bindtap="onTap">点击</view>

onTap(e){console.log(e.currentTarget.dataset.elementType);// undefinedconsole.log(e.currentTarget.dataset.elementtype);// 'image'}

官方原话：

连字符写法会转换成驼峰写法，而大写字符会自动转成小写字符。

规则：data-elementType中的大写字母会被自动转换为小写，最终取到的 key 是elementtype。

建议：命名时统一用全小写 + 短横线，比如data-element-type，取值时用dataset.elementType（短横线后字母大写）。

转换规则对照：

二、事件对象取值：target 与 currentTarget 的差异

嵌套标签场景下，这个差异会导致取值失败。

<viewdata-id="123"bindtap="onTap"><imagesrc="..."/></view>

点击image时：

• e.target.dataset.id→undefined（因为target是实际被点击的image节点，上面没有绑定data-id）
• e.currentTarget.dataset.id→'123'（currentTarget是绑定事件的那个view节点）

规则：e.target是事件最初触发的节点，e.currentTarget是绑定事件处理函数的节点。取值统一用e.currentTarget。

补充：dataset取到的值全部是字符串类型，即使绑定的是数字。需要做数值计算时手动Number()转换。

三、生命周期顺序：组件早于页面

很多人直觉认为“先有页面，再有组件”，实际顺序是反的：

Component.created → Component.attached → Page.onLoad → Page.onShow → Component.ready → Page.onReady

典型问题：页面onLoad里await请求数据后传给子组件，子组件的attached早就跑完了，拿到的只能是初始值（通常是undefined）。

解决方案：用wx:if卡住组件渲染时机，等数据到位后再让组件出现；或者让子组件用observers监听properties变化来响应数据更新。

四、onLoad 和 onReady 无依赖关系

onLoad不会等待onReady，两者是独立触发的事件。

onLoad触发时页面还没渲染完成，在它里面操作渲染相关的 API（如wx.setNavigationBarTitle）可能不生效。官方建议这类操作放在onReady之后。

五、iOS 上 scroll-view 嵌套 textarea 会空白

这是 iOS 上的经典兼容性问题。

现象：scroll-view里的textarea输入内容或触发setData重绘后，整个区域变成空白。

原因：scroll-view在 iOS 上创建独立滚动渲染层，键盘上推和滚动层冲突，或setData重绘时把textarea内容层清空，导致可视区域计算错位。

解决方案：

• 如果页面不需要滚动，直接用普通view替代scroll-view。
• 如果必须保留，关掉textarea的adjust-position，并确保scroll-view父容器用固定高度。

六、原生组件的层级霸权

camera、map、video等原生组件默认脱离文档流，z-index对其无效，且会遮挡普通组件。

解决方案：用cover-view和cover-image覆盖原生组件。

七、setData 的性能陷阱

1. 更新无关数据也会触发渲染

即使只更新一个用于 JS 逻辑判断、WXML 里根本没绑定的字段，只要它放在data里，也会触发逻辑层到渲染层的通信和渲染流程。

建议：用不到的数据不要放进data。

2. 组件 Shadow Tree 的体量影响更大

影响setData性能的首要因素不是数据量大小，而是组件 Shadow Tree 的总节点量。在节点数庞大的页面里setData，即使只传一个字段，开销也可能不小。

建议：高频更新的部分封装成独立组件，把setData限定在组件内部，减少 Shadow 树的规模。

3. setData 频率红线

官方性能评分规则明确要求每秒调用setData不超过 20 次。过于频繁的调用会导致逻辑层 JS 线程持续繁忙，无法及时响应用户操作。

八、总结

这些坑的共同特点：在开发者工具模拟器上往往看不出问题，只有上真机、特别是 iOS 真机，或者数据量上来之后才会暴露。写代码时对边界条件多留一步判断，能省下很多排查时间。