uni.previewImage 点开只显示一张图，因未正确传入图片URL数组和当前索引（须为数字下标而非路径字符串），且需确保数组纯净、无嵌套或空值，删除图片后应同步更新预览索引或关闭预览框。
uni.previewImage 为什么点开只显示一张图？
因为 uni.previewImage 默认需要传入完整的图片 URL 数组和当前索引，只传单个路径或数组拼接错误，就会“卡”在第一张。常见写法错误是把 current 设成图片路径字符串，但实际应设为该路径在数组中的下标（数字），否则无法定位。
正确做法是确保：urls 是一个纯字符串数组（如 ['/tmp/a.jpg', '/tmp/b.png']），current 是对应索引（如 2）；且数组不能嵌套、不能含空值或 undefined。
- 预览前先校验
this.selectedImages[index]是否存在，避免越界 - 如果用的是对象数组（如
{ path: 'xxx', id: '1' }），必须提取path字段组成新数组再传给urls - H5 端不支持
current为路径字符串，必须为数字索引；小程序端部分版本容忍路径，但不推荐依赖
删除图片后预览数组错乱怎么办？
直接用 splice(index, 1) 删除后，原数组长度变短，但用户可能还在滑动预览 —— 此时 current 索引已失效，导致点开白屏或跳到错误图片。本质是 UI 状态（预览位置）和数据状态（图片列表）没同步。
解决思路不是“删完就重置预览”，而是让预览逻辑感知删除动作：
- 删除前记录被删项的
id或path，删完后从新数组里重新查找它的位置，作为新的current - 更稳妥的做法：删除后关闭预览框（
this.previewVisible = false），避免状态残留 - 如果用了自定义预览组件，应在组件内监听
imageList变化，自动校准当前索引
uni.chooseImage 的 sizeType 和 sourceType 怎么配才不翻车？
默认 sizeType: ['original', 'compressed'] 会让用户在相册里看到两份重复缩略图，体验差；而全用 ['original'] 在低端安卓机上极易触发内存溢出闪退 —— 实测 9 张原图在 Android 6.0 设备上平均占用 300MB+ 内存。
推荐组合：
-
sizeType: ['compressed']：99% 场景够用，压缩图体积小、加载快、兼容性稳 -
sourceType: ['album']：先禁用相机入口，避免用户拍完立刻上传（未裁剪/光线差/文件大）；如需拍照，单独加一个「拍照」按钮，走uni.chooseImage({ sourceType: ['camera'] })分离流程 - 加
count: 9但前端要限制最大可选数，防止用户一次选 20 张导致后续上传队列阻塞
预览时点击删除按钮没反应？
常见原因是事件冒泡冲突：@click，点击删除图标时，父级的预览事件先触发，把删除点击吞掉了。
两个低成本解法：
- 给删除按钮加
@click.stop，阻止事件冒泡到父容器 - 把删除图标改成
或绝对定位的pointer-events: auto（H5）或确保层级高于 image（小程序） - 别用
image标签的@click做预览入口，改用外层包裹view，这样删除按钮和预览触发区物理隔离
真正难处理的其实是「预览态下的删除」—— 即全屏预览时想删当前这张。这需要自定义预览组件，在工具栏加删除按钮，并通过 ref 或事件总线通知主页面执行删除逻辑。原生 uni.previewImage 不提供此能力，硬加会破坏跨平台一致性。
