uni-app朋友圈九宫格用flex+calc布局最稳，image设mode="aspectFill"，外层flex-wrap，子项flex:0 0 calc(33.33%-4px)；多图上传前需前端压缩至宽1200px、质量0.8、转jpg并限5MB；上传用3并发队列控制，带唯一fileId确保顺序；previewImage需绑定@click而非默认行为，传完整图数组且严格对齐索引。
uni-app 里怎么实现朋友圈式多图九宫格布局
直接用 flex + calc() 控制单图宽高比最稳，别信“自适应栅格组件”——那些在 iOS 微信 WebView 里容易错行或缩放异常。
常见错误是给 image 设 width: 100% 却没限制父容器高度，结果图片挤压变形；或者用 v-for 渲染后直接套 display: grid，但在 H5 端部分安卓机不兼容 grid-template-columns: repeat(auto-fill, ...)。
- 每张图用
<image>标签，mode="aspectFill"保证裁剪一致，禁用scaleToFill - 外层容器设
display: flex; flex-wrap: wrap;，子项用flex: 0 0 calc(33.33% - 4px)（减去间隙），间隙统一用margin而非gap（H5 兼容性差） - 最多显示 9 张，超出时用
+N文字盖在最后一张图上，不要隐藏或滚动——朋友圈原生逻辑就是截断+提示
uni-app 多图上传前怎么压缩并限制尺寸
微信小程序和 App 端对单图体积敏感，不压缩直接传，iOS 容易卡在 uploadFile:fail timeout，安卓可能触发平台限频；H5 端更得防用户选了 20MB 的 PNG。
别依赖后端校验：上传失败再提示，体验已经崩了。必须前端拦截 + 压缩 + 格式转换。
- 用
uni.chooseImage的sizeType: ['compressed']（仅 App 和小程序有效），H5 必须自己调canvas压缩 - 压缩目标：宽度统一到 1200px，质量设
0.8，格式转jpg（PNG 透明通道在朋友圈里无意义还更大） - 传之前检查
tempFile.tempFilePath大小，>5MB 就uni.showToast({title: '图片太大，请重新选择'})并return
uni-app 上传多图时如何避免并发失败和顺序错乱
直接 for 循环里写 uni.uploadFile，大概率出现「上传完成但回调乱序」「部分请求被 cancel」——因为微信小程序有并发数限制（默认 10），且 uploadFile 不是 Promise 化的。
别手写 setTimeout 串行，太糙；也别直接用 Promise.all，会压垮底层连接池。
- 用
uni.uploadFile+ 手动队列控制：每次只发 3 个请求，任一完成就补一个，保持管道常开 - 每张图上传前生成唯一
fileId（比如Date.now() + Math.random().toString(36).substr(2, 9)），传参带过去，后端存库时按这个排序 - 成功回调里把服务器返回的
url按原始数组索引存进新数组，而不是 push 进去——否则顺序保不住
为什么 uni-app 的 uni.previewImage 在朋友圈样式里要点两次才能放大
因为默认 uni.previewImage 绑定的是整个 <image> 标签，而你的九宫格里图是小尺寸缩略图，用户第一次点是“选中”，第二次才是“预览”——这不是 bug，是设计缺陷。
真实场景下，用户想点哪张图就立刻放大哪张，不是先点再确认。
- 给每个
<image>加@click="preview(index)"，在preview方法里构造完整图 URL 数组（不是缩略图地址） - 确保数组顺序和 UI 显示顺序严格一致，否则点第三张却放大了第一张
- iOS 微信里如果图地址带参数（如
?t=123），要加encodeURIComponent，否则previewImage直接白屏
最麻烦的其实是图加载状态同步：缩略图还没出来，用户就点了空白区域。得在 image 上加 @load 和 @error，控制 loading 图标显隐，这个细节 80% 的人会漏。
