uni.previewImage 是最稳的起点，但 current 必须是 urls 数组中某个元素的完整字符串值，且大小写、协议、路径必须完全一致；image 点击需加 @click.stop 保障手势正常；图片地址须为 HTTPS 或 /static/ 绝对路径。
uni.previewImage 是最稳的起点，但 current 必须是字符串
直接用 uni.previewImage 是跨端兼容性最好的方案，不用额外引入插件或封装组件。但它最容易出错的地方是 current 参数——很多人传数字索引（比如 0），结果预览打开后总卡在第一张图或白屏。current 必须是 urls 数组中某个元素的**完整字符串值**，且大小写、协议、路径必须完全一致。
常见错误场景：
- src 是
https://a.com/1.jpg，但 urls 里写成https://a.com/1.JPG→ 不匹配 - 图片来自
uni.chooseImage，tempFilePaths是本地临时路径，但小程序要求 HTTPS 或/static/绝对路径 → 预览失败 - H5 端 src 是相对路径（如
./assets/a.png），未转为绝对 URL → 白屏或 404
实操建议：
- 构造
urls时，统一用响应式变量（如this.imgList），避免 v-for 渲染时闭包捕获旧值 - 单图预览：直接传
[src]，current: src - 多图预览：确保
urls和current都来自同一数据源，不要手动拼接或截断
@click.stop 是 App 和小程序端手势正常的前提
image 组件默认不触发原生触摸事件，尤其在 App 和微信小程序端，不加 @click.stop 或 @touchstart.stop，会导致双指缩放、拖拽等手势被父容器拦截或失效。
这不是可有可无的修饰符——它是让 uni.previewImage 内部手势识别能正常工作的底层条件。
实操建议：
- 永远给 image 的点击事件加
@click.stop，例如：<image :src="item.src"></image> - 如果页面用了 scroll-view 或 swiper，且内部嵌套 image，更需加
.stop，否则滑动时误触会触发预览 - 不要用
@click.native.stop，uni-app 的 image 是自定义组件，.native不生效
HTTPS / 绝对路径不是“建议”，是小程序和 App 端的硬性要求
微信小程序和 App（尤其是 iOS）对 uni.previewImage 的图片地址有明确限制：必须是 HTTPS 协议的网络地址，或以 /static/ 开头的本地绝对路径。相对路径（../../assets/xxx.png）、file://、base64、甚至 http 都会失败。
这个限制在 H5 端不生效，所以开发时容易忽略，一到真机测试就卡住。
实操建议：
- 网络图：确认后端配置了 CORS（
Access-Control-Allow-Origin: *），否则 App 端可能加载空白 - 本地图：把图片放进
/static/目录，引用时写/static/xxx.jpg，不要用require()或动态拼接 - 临时文件（如
uni.chooseImage返回的tempFilePath）：App 端建议先用uni.downloadFile缓存到本地再预览，避免 file:// 路径不稳定
自定义预览组件只在需要深度定制时才值得投入
如果你只需要双指缩放、滑动切换、下载功能，uni.previewImage 完全够用。只有当出现以下情况，才考虑用 movable-area 或 swiper 自建：
- 要叠加 UI 元素（如图片标题、分享按钮、标注工具）
- 需控制关闭动画、背景蒙层透明度或手势灵敏度
- 业务要求长按保存、滤镜切换、多图分组浏览等扩展交互
但要注意：自定义方案会显著增加维护成本，且各端手势兼容性差异大（比如鸿蒙对 movable-view 的 scale 支持不一致）。多数项目卡点不在“能不能做”，而在“有没有必要自己做”。
真正容易被忽略的是性能边界——App 端预览 5MB 原图，内存飙升、滑动卡顿；而 uni.previewImage 内部做了平台级优化，这点它比你写的任何自定义组件都可靠。
