uni-file-picker九宫格上传需显式设mode="grid"、limit和file-mediatype，H5与小程序路径处理不同，预览前须校验临时路径有效性并补全数量，避免黑屏或卡死。
直接用 uni-file-picker + flex 布局就能跑通，不需要自己写预览逻辑或 canvas 手势——但必须处理好图片路径、数量补全和点击传参这三处，否则 H5 黑屏、小程序报错、App 预览卡死。
uni-file-picker 九宫格上传配置关键点
它不是单纯“显示九宫格”，而是把选择、预览、删除、上传链路都封装好了，但默认行为容易踩坑：
-
mode="grid"必须显式声明，否则默认是 list 模式 -
:limit="9"控制最大张数，但若后端允许更多，别只靠这个限制——用户可能选完再删，v-model绑定的数组长度才是真实值 -
file-mediatype="image"和file-extname="jpg,png,webp"要配齐，否则 iOS 微信里会弹出“不支持该格式”却无提示 - H5 端不支持
sizeType: ['compressed']，必须自己用 canvas 压缩；App 和小程序端开启压缩能大幅降低上传失败率
预览图点击传参必须严格对齐 urls 和 current
uni.previewImage 不接受索引，只认字符串路径——而 uni-file-picker 返回的是临时路径（如 tempFile.tempFilePath），这些路径在 H5 下无法直接预览：
- 小程序和 App：可直接把
tempFilePaths传给urls，但current必须是其中某一项完整字符串（大小写、斜杠方向都不能差） - H5：必须先上传到 CDN 或本地服务，拿到完整 URL（
https://...）再构造urls数组，否则黑屏 - 常见错误：点击第 3 张图，却传了
urls[2]的索引值当current，实际要传urls[2]这个字符串本身 - 过滤空项：
const validUrls = tempFilePaths.filter(u => u && typeof u === 'string')，否则数组里混入undefined会导致整个预览失败
图片数量不足 9 张时，最后一行不能留空位
微博实际效果是左对齐、不撑满，不是用空 view 占位——那会在小程序里参与 flex 计算，导致宽度错乱：
- 用 JS 补足至 3 的倍数：
const paddedList = [...pics, ...Array(3 - pics.length % 3).fill(null)]，然后v-for渲染，每项加v-if="item" - 别用
width: 33.333%硬写，改用flex: 0 0 calc(33.333% - 6rpx)（减去左右 margin），避免 box-sizing 失效导致总宽超 100% - 图片外层必须包
view并设overflow: hidden，否则 App 端image不响应 height，会拉伸变形 -
mode="aspectFill"是唯一推荐值，scaleToFill会失真，aspectFit留白破坏网格对齐
真机调试时图片加载闪烁、预览卡顿
这不是样式问题，是 uni-app 生命周期和图片加载机制叠加导致的 layout 反复触发：
- 给每张图的外层
view设固定宽高比：padding-bottom: 100%+position: relative，image设position: absolute; width: 100%; height: 100%; - 禁用
scroll-view包裹九宫格列表，改用页面原生滚动，否则 iOS 微信里大量image重绘直接卡死 - App 端预览大图前，建议对原图做
q=60压缩再传，否则解码时 OOM 崩溃概率极高 - 别在
@select回调里直接调uni.previewImage——等所有图片onload完再触发，否则部分路径还没就绪
真正难的不是布局，是跨端路径一致性、数量动态补全、以及预览前的加载状态兜底——这些点漏掉一个，真机上就会表现不一致。尤其 H5 和小程序之间，临时路径和网络路径的切换最容易被忽略。
