真正有效的占位模糊加载需满足视觉过渡、资源预判、渲染不卡顿三点：用opacity过渡替代v-if切换，placeholder前置请求阶段，小程序用canvas模拟模糊，h5用stackblur，app用原生插件，占位图须小而准且宽高比一致。
UniApp 里图片加载时直接空白或突兀出现，是性能和体验双失分点。真正有效的“占位模糊加载”，不是单纯加个 loading 动画，而是让视觉有过渡、资源有预判、渲染不卡顿——这三点缺一不可。
为什么 @load + 占位图还不够？
很多人用 @load 隐藏 placeholder，但实际测试中会发现：网络慢时 placeholder 显示太久，用户以为卡了；图片加载完成瞬间“啪”一下弹出，缺乏动效连贯性；更关键的是，@load 触发时机依赖图片解码完成，在低端安卓机上可能延迟数百毫秒，导致占位图消失滞后。
-
@load不代表图片已绘制到屏幕，只代表 DOM 加载完成（H5）或 native 图片资源就绪（小程序/App） - 纯
v-if/v-else切换两张图，会触发两次 layout 和 paint，尤其在列表中频繁操作易掉帧 - 本地 placeholder 图如果未压缩或尺寸过大，反而拖慢首屏渲染
用 opacity + transition 实现平滑淡入
比切换 DOM 更轻量的方案是控制透明度，复用同一个 <image></image> 元素，避免重绘开销。关键在于把“加载中”状态前置到请求发起阶段，而非等待 @load。
- 初始
:src设为 placeholder 路径，同时设置:class="{ 'loaded': isLoaded }" - 在
onLoad回调里仅设this.isLoaded = true，不改src—— 真正的业务图通过background-image或 canvas 预加载后注入 - CSS 中定义
.loaded { opacity: 1; transition: opacity 0.25s ease-out; }，未加载时 opacity 为 0.3～0.4，保留轮廓感 - 避免对
<image></image>直接设opacity: 0后再1，部分安卓 WebView 会闪白，改用rgba(0,0,0,0.01)作底色过渡更稳
小程序端必须绕开 filter: blur()
微信/支付宝小程序的 <image></image> 组件不支持 CSS filter，写上去完全无效。想实现“模糊占位→清晰加载”的渐进效果，得用 canvas 做中间层。
- H5 端可用
stackBlur.canvasRGBA对 placeholder 图做实时模糊，再toDataURL赋给src - 小程序端不要尝试
getImageData（真机常返回空），改用离屏 canvas + 多次drawImage模拟块状模糊（如 8×8 像素采样），性能稳定 - App 端建议用原生插件（如
uni-app-plugin-image-blur），JS 层做高斯模糊 > 3px 在中低端机上极易卡顿 - 所有平台都禁用
mode="widthFix"配合模糊占位，该模式强制等比缩放+插值，会让模糊图边缘发虚
占位图本身要“小而准”
一张 2KB 的灰度 SVG 占位图，比 15KB 的 PNG 占位图更能扛住弱网。模糊效果只是过渡手段，核心是让占位图足够快地撑起布局。
- 优先用内联 SVG 作 background，避免额外 HTTP 请求：
background: url("data:image/svg+xml,%3Csvg...%3E") - 不用 base64，小程序对过长 data URI 解析不稳定；H5 端 base64 超过 4KB 可能触发 Safari 内存警告
- 占位图宽高比必须与目标图一致，否则
mode="aspectFill"会裁切错位，模糊过渡失去意义 - CDN 上的占位图开启
Cache-Control: public, max-age=31536000，确保长期缓存
最易被忽略的一点：模糊占位不是为了“看起来高级”，而是掩盖图片加载的不可控延迟。所以它的模糊半径、淡入时长、占位图尺寸，都要按真实弱网（如 3G、250ms RTT）下的加载耗时来反推，而不是凭感觉调参。
