在微信小程序开发中，数据通常来自远程接口，从发起请求到渲染完成存在明显延迟。如果页面初始没有任何占位结构，等到数据返回再动态创建列表或卡片，视图会突然撑开甚至重排，造成肉眼可见的抖动。骨架屏就是一种在加载阶段用静态灰块模拟页面结构的方案，它让页面在等待期间维持稳定布局，从而消除抖动。
骨架屏防抖的底层原理
小程序渲染基于双线程模型，逻辑层通过setData把数据发送到视图层，视图层再做节点创建与布局。当页面初始wxml中没有对应节点，而数据到达后一次性渲染出大量元素，渲染引擎需要重新计算所有相关节点的位置和尺寸，这就触发了回流。回流期间页面会发生位移，表现为抖动或闪跳。
骨架屏的思路是在首屏wxml中直接写好与真实内容结构一致的占位容器，例如相同宽高的view块、相同行数的文本行。这些节点在页面加载时就已经参与布局，尺寸固定。数据返回后，用wx:if将骨架屏隐藏，同时显示真实内容。由于真实内容的外部容器尺寸与骨架屏接近，视图层只需做局部替换，不会整体重排，抖动就被抑制了。
从性能角度看，骨架屏本身也是节点，过多过深会增加初始渲染负担。因此占位结构应当适度简化，只保留影响布局的关键块，比如图片区域、标题行、按钮条，而不必精细到每一个文字。这样既能防抖，又不会拖慢首屏。
使用WXSS与条件渲染实现骨架屏
最常见做法是维护两个布局区块：一个骨架屏区块，一个真实内容区块。用同一个状态变量控制显隐，保证二者不会同时出现。下面示例展示了一个商品列表的简化骨架屏实现。
<view class="page">
<block wx:if="{{loading}}">
<view class="skeleton-item" wx:for="{{skeletonList}}" wx:key="id">
<view class="skeleton-img"></view>
<view class="skeleton-line"></view>
<view class="skeleton-line short"></view>
</view>
</block>
<block wx:else>
<view class="goods-item" wx:for="{{goods}}" wx:key="id">
<image class="goods-img" src="{{item.img}}"></image>
<view class="goods-title">{{item.title}}</view>
<view class="goods-price">{{item.price}}</view>
</view>
</block>
</view>
对应的WXSS中，骨架屏块使用灰色背景和固定高度，并可以加上微弱的闪烁动画提升感知流畅度。注意骨架屏里的<view>尺寸要参照真实商品卡片来写，例如图片固定200rpx见方，标题行高40rpx，这样隐藏骨架时内容填入不会撑开容器。
在逻辑层，页面onLoad时设loading为true并请求接口，成功回调里赋值goods并把loading改为false。若接口失败也应关闭骨架屏并展示错误提示，避免骨架永远停留。这种条件渲染方式简单直观，适合大多数列表与详情页。
官方骨架屏生成能力与自定义方案对比
微信开发者工具提供了自动生成骨架屏的功能，右键wxml选择生成骨架屏，会产出一份带.skeleton后缀的模板与样式。它的优势是能按当前页面真实节点比例生成占位，减少手工估算误差。但自动生成往往节点较多，需要手动删减非关键块。
自定义方案则完全由开发者控制结构和样式，能针对业务做最简占位。例如瀑布流页面，自动生成可能把每个图片都画成块，而自定义只需在列容器里放固定高度的灰条。下表列出两者差异：
| 维度 | 官方生成 | 手动编写 |
|---|---|---|
| 准确度 | 高，贴近真实布局 | 依赖经验，可能偏差 |
| 节点量 | 偏多，需优化 | 精简，可控 |
| 维护成本 | 页面改版需重新生成 | 同步修改两处布局 |
实际项目中可以混合使用：先用工具生成初版，再剔除冗余节点。无论哪种方式，都要在真机上测试抖动是否消失，因为模拟器和真机渲染时机略有不同。另外，骨架屏不应遮挡用户操作入口太久，若接口超过一定时间，可结合重试或缓存策略减少等待。
最后要强调的是，骨架屏只是体验优化手段，不能替代接口性能优化。若数据接口本身耗时两秒以上，即便有骨架屏，用户仍会觉得慢。因此要把骨架屏和请求合并、缓存、分页加载等策略一起用，才能从根本上解决加载阶段的各类体验问题。