必须手写骨架屏，禁用自动生成插件；用v-show而非v-if控制显隐以保DOM稳定；loading需在uni.request调用前设为true，并配合$nextTick或setTimeout延时隐藏，确保占位不闪、不白、不跳。
必须手写，不能依赖插件生成；v-show 控制显隐，不是 v-if；显示时机要卡在请求发出前，不是等接口返回后才设 loading = true。
为什么不能用 v-if 或自动生成插件
uni-app 编译为小程序时，不走完整 DOM 流程，所有基于 Webpack AST 分析或运行时 DOM 注入的插件（比如 vue-skeleton-webpack-plugin、uni-skeleton）都会失效。v-if 会导致骨架节点被销毁，真实内容挂载时重排布局，iOS WebView 中滚动位置丢失、页面闪一下再跳出来是常态。
- 微信小程序平台禁止运行时动态挂载节点，
uni.createSelectorQuery查不到未渲染的骨架 - 所谓“一键生成”的
.skeleton.wxml只能当参考，直接搬进.vue文件会错位、样式崩、动画不触发 - 骨架组件内若用了
slot或响应式props，v-show 下仍可能触发无谓更新，拖慢渲染
怎么写一个稳定可用的骨架组件
骨架组件要轻量、静态、跨端一致。别堆 view 数量，按真实页面区块来：列表页用 uni-list 模拟几行占位块，详情页带头图 + 标题段 + 正文段，表单页重点占位输入框和按钮。
- 用
写结构，避免 data 响应式开销 - 颜色统一用
#f2f2f2（背景）和#e4e4e4（色块），规避暗黑模式翻车 - 图片占位必须用
- 所有尺寸用
rpx或固定px，禁用百分比宽高（小程序中计算不稳定）
loading 状态怎么控制才不闪不白
骨架一闪就消失、内容没对齐，90% 是 loading 状态没和数据流节奏对齐。关键不是“接口回来了”，而是“视图真的刷新了”。
-
this.loading = true必须写在uni.request调用前，不是 success 回调里 - 接口返回后，先赋值数据（如
this.list = res），再this.$nextTick(() => { this.loading = false }) - 小程序端若嵌套深，建议加
setTimeout(() => { this.loading = false }, 16)保底 - 异常时不要清空骨架，保留并加「重试」按钮——白屏比灰屏更让人焦虑
CSS 动画在各端怎么写才不报错不失效
H5 支持 linear-gradient + animation，但微信小程序不支持 background-image 动画，App 端 WKWebView 对 -webkit- 前缀敏感。统一用最稳的方案：纯色 + opacity 脉冲动画。
- 动画定义必须包在
/* #ifdef H5 */或/* #ifdef APP-PLUS */条件编译块里 - 避免用
::after伪元素画线条，低端安卓机渲染异常，改用空height/width - 所有动画 duration 控制在 1.2–1.5s，太短用户感知不到，太长拖慢首屏节奏
- 务必设最小展示时间（如
setTimeout(() => { this.loading = false }, 300)），防网络极快时骨架闪一下就没了
真正难的不是画几个灰色方块，而是让骨架的出现、退场、异常兜底全部卡在数据流的真实节奏上——loading 设早了，页面还没 ready 就占位；设晚了，白屏已露馅；切得太急，DOM 还没 render 完就藏了。这些细节不调通，骨架屏反而成体验负资产。
