结论：uni-app微博式多图发布需构建可响应、可删减、跨端兼容的链路，核心是统一处理tempfilepaths渲染、严格校验previewimage参数、分平台控制并发上传及count限制。ios临时路径需立刻转可用url，h5用blob url，小程序需https或云链接；current必须传数字索引，urls须过滤无效项；上传须限并发（建议3个）、独立维护状态、避免promise.all；count需按平台降级（小程序/ app 9张、h5 20张、安卓厂商可能限5张）。
直接说结论：uni-app 里实现微博式发布页多图选择+预览，核心不是堆 API，而是把 uni.chooseImage、uni.previewImage 和状态管理串成一条可响应、可删减、跨端不白屏的链路。iOS 真机上临时路径一丢就失效，H5 里 base64 太大卡顿，微信小程序不认本地路径——这些坑踩一遍，UI 就废一半。
uni.chooseImage 返回的 tempFilePaths 怎么安全渲染成预览图？
真机（尤其 iOS）返回的是沙盒内临时路径，不能直接当 <image src=""></image> 的值用；H5 下是 blob URL，能直接渲染；小程序部分版本支持临时路径直显，但不可靠。
- 统一做法：选图后立刻用
uni.getImageInfo提取宽高并生成可用 URL（App 和小程序会自动转为可渲染路径，H5 则 fallback 到原 blob URL） - 别直接 push
res.tempFilePaths到数组——要 map 成对象结构：{ tempPath: '', url: '', status: 'ready' }，否则删除时索引错乱、重复选图逻辑崩坏 - iOS 上临时路径有效期极短，
url字段必须在chooseImage success回调里同步赋值，不能延迟到上传后再处理 - H5 若需压缩，可在
getImageInfo后用 canvas 重绘 +toDataURL转 base64，但注意单图超 2MB 会触发内存警告
点击某张图预览时，为什么总跳到第一张？
根本原因是 uni.previewImage 的 current 参数类型和 urls 数组内容没对齐。传字符串匹配失败就 fallback 到第 0 项，传数字索引又容易因动态列表导致错位。
-
current必须传数字索引（如2），不要传item.url—— 即使看起来一样，大小写、查询参数、编码差异都会让===匹配失败 -
urls数组必须过滤掉空值、null、undefined和非图片路径（比如误混入视频地址），否则 iOS App 端预览器直接卡死无报错 - v-for 里绑
@click="previewImage(index)"是危险写法：如果列表做过 filter 或分页，index就不是原始数组下标。稳妥做法是传item，再用this.images.indexOf(item)查真实索引 - 所有路径必须协议一致：H5 要求 HTTPS（HTTP 被拦截），小程序强制 HTTPS，App 端本地路径（
tempFilePath）可用但不能混进 HTTPS 链接数组里
多图上传时并发控制和失败重试怎么落地？
uni.uploadFile 是单文件接口，所谓“多图上传”本质是多次调用。不加控制，iOS App 会直接拒绝后续请求，微信小程序并发超 10 个就 pending 卡住。
- 别用
Promise.all—— 一旦某张失败，整个上传流程中断。改用串行或带限流的并行（如每次最多 3 个） - 每张图上传前检查
name参数是否匹配后端字段：常见错误是固定写name: 'file'，但后端接收的是images[]或photo，导致 400 - 上传状态必须独立维护：
status: 'uploading' / 'success' / 'fail'，失败后保留tempPath，用户点击重试时直接复用，不用再选图 - 进度回调只在 App 和 H5 生效，小程序不支持
progress，需用计时器模拟或干脆隐藏进度条
最易被忽略的一点：uni.chooseImage 的 count 参数在不同平台实际限制不同——微信小程序最多 9 张，但某些安卓厂商系统（如华为 EMUI）会拦截超过 5 张的请求且无提示；iOS 在相册模式下选太多图会触发系统内存警告。所以 maxCount 不只是 UI 限制，得结合平台做降级：App 端设 9，H5 设 20，小程序设 9 但加兜底校验。
