骨架屏不能缩短真实加载时间，但能通过结构化占位、微动效和渐进加载提升感知速度20%–30%，并需兼顾深色模式、列表延迟入场、可访问性（如aria-busy）等细节。
骨架屏不能缩短真实加载时间，但它能显著改善用户“感觉上”的等待时长。关键在于提前建立预期、稳定视觉结构、减少焦虑感。
用结构代替空白，让用户知道“内容正在路上”
白屏或旋转图标会让用户怀疑页面是否卡住；而骨架屏展示标题区、图片位、段落块等轮廓，大脑会自然解读为“页面结构已就绪，内容正填充进来”。这种心理暗示能把感知加载速度提升20%–30%。
- 避免全屏 loading 动画，改用与最终布局一致的灰色占位块
- 优先渲染首屏关键区块（如头像、主标题、首张图），次要内容可延后占位
- 保持骨架元素宽高与真实内容一致，防止加载完成时页面跳动（影响 CLS）
搭配微动效，增强“正在加载”的可信度
静态灰色块略显呆板，加入柔和的 shimmer（流光）动画，能模拟光线扫过页面的效果，强化动态反馈。
- 推荐使用线性渐变 + 水平位移动画，循环时间控制在1.2–1.5秒之间
- 深色模式下同步调整骨架色值（如从 #e0e0e0 改为 #3a3a3a），保持对比协调
- 列表类场景中，可对每行骨架添加轻微延迟入场，模拟逐条加载感
按需加载，让骨架屏成为渐进体验的一环
骨架屏不是孤立的加载状态，而是渐进式内容呈现的第一步。它应与数据分片、懒加载、虚拟滚动等策略协同工作。
- 先显示顶部导航+骨架主体，再请求正文；正文加载中，骨架继续保留在原位
- 长列表用骨架项占位，配合虚拟滚动，避免一次性渲染数百个占位节点
- 在微信小程序中，直接用开发者工具生成 .skeleton.wxml，自动匹配 WXML 结构
关注可访问性，不让任何用户掉队
屏幕阅读器用户同样需要感知加载状态变化。纯视觉的骨架屏对他们无效，必须补充语义化提示。
- 为骨架容器添加 aria-busy="true" 和 role="status"
- 使用 announceLoadingStatus 等属性（如 EUI、MUI 提供的 API）触发语音播报
- 加载完成后及时移除骨架并设置 aria-live="polite"，通知内容已就绪
