uni.chooseMedia返回的是tempFiles对象数组，正确取路径为res.tempFiles[0].tempFilePath；H5端thumbTempFile可能为空，iOS临时路径有效期极短，需立即上传。
uni.chooseMedia 返回的路径怎么直接用于上传
不能直接把 res.tempFilePaths[0] 当成字符串传给 uni.uploadFile 的 filePath——这是老写法，uni.chooseMedia 返回结构完全不同。它返回的是 tempFiles 数组，每个元素是对象，含 tempFilePath 字段。
常见错误：写成 res.tempFilePaths[0] 或 res.tempFiles[0]（漏掉 .tempFilePath），运行时直接报 undefined 或 “file not found”。
- 正确取法：
res.tempFiles[0].tempFilePath - H5 端注意：
thumbTempFile可能为空，别硬取res.tempFiles[0].thumbTempFile.tempFilePath - iOS 真机上临时路径有效期极短，拿到后必须立刻上传，不能存变量延迟调用
uni.uploadFile 为什么传了路径却提示“文件不存在”
根本原因是没理解 uni.uploadFile 的参数逻辑：它要的是本地临时文件路径（字符串），不是 base64、不是 blob URL、更不是服务器地址。但路径必须合法且未过期。
典型现象：H5 上能传，小程序白屏或报错；App 端提示 “file not found”；微信小程序开发版静默失败。
-
filePath必须是tempFiles[i].tempFilePath这种格式，不能是数组、不能带前缀（如file://） - 微信小程序要求
envVersion为release或trial才能读取相机/相册文件，开发版需手动配置或切环境 - App 和小程序端不支持 H5 的
blob:URL，所以千万别用URL.createObjectURL生成的地址传过去
点击上传按钮时怎么避免重复触发或状态错乱
用户点一次“上传”，结果发了 3 次请求，或者上传中又点了“选择图片”，导致 imageList 和 tempFiles 不同步——这类问题几乎都出在状态管理没隔离。
关键不是“能不能传”，而是“什么时候传、传哪个、传完怎么清理”。尤其多图场景下，临时路径和 UI 渲染路径（url）必须分开维护。
- 每次
chooseMedia后，用map构造新数组：this.images = res.tempFiles.map(f => ({ tempPath: f.tempFilePath, url: f.tempFilePath, status: 'ready' })) - 上传时遍历
this.images，对每项单独调uni.uploadFile，别用files数组批量传（该参数仅 App/H5 2.6.15+ 支持，且各端行为不一致） - 上传开始设
status: 'uploading'，成功后改'success'，失败后保留原tempPath方便重试，别直接从数组删掉
为什么 iOS 上点“拍照”直接报 “no suitable source”
不是权限问题，也不是 API 写错，是 sourceType 数组长度惹的祸。iOS 要求至少两个选项才弹窗，哪怕你只想让用户拍照。
Android 和 H5 不校验这个，所以开发时测不出，一到 iOS 真机就崩。
- 只想要拍照：写
['camera', 'album']，别写['camera'] - 只允许相册：同样得写
['album', 'camera']，iOS 不认单元素数组 - H5 端
camera实际降级为文件选择框，别指望真调起摄像头
最易被忽略的一点：uni.chooseMedia 返回的 tempFiles 是临时对象，里面字段名（如 tempFilePath）大小写敏感，少个字母或驼峰错位就拿不到路径。别依赖 IDE 自动补全，翻文档核对一遍再写。
