结论：小程序必须手写 touchstart/touchmove/touchend，web/h5 可用 sortablejs；相册需统一处理路径、方向、格式；排序持久化应延迟批量提交并加版本校验。
uni-app 中图片拖拽排序用 touchstart/touchmove 还是 sortablejs？
直接说结论：uni-app 的 web-view 或 H5 端可用 sortablejs，但小程序（微信、支付宝等）不支持 DOM 拖拽事件，必须手写 touchstart/touchmove/touchend 逻辑，且要处理 touch 坐标映射、元素占位、列表重排时机等细节。
常见错误是直接套用 Web 端的 dragstart + drop，结果在小程序里完全无响应；或者只监听 touchmove 但没做节流，导致卡顿或误判。
- 用
touchstart记录起始索引和初始触摸坐标（e.touches[0].pageX/Y） - 在
touchmove中计算当前触摸点与各 item 中心的垂直距离，找出最接近的目标索引（仅需判断 Y 轴，避免左右滑动干扰） - 用
Array.splice()实时更新数组，但注意：不能直接修改原数组引用，需用this.$set或解构赋值触发响应式更新 - 拖拽过程中用
z-index和transform: scale(1.05)做视觉反馈，但小程序里transform对view支持有限，建议改用style="top: {{offsetTop}}px"动态偏移
uni-app 相册管理怎么兼容 iOS/Android/小程序多端获取图片？
关键不是“怎么选图”，而是“选完之后怎么统一处理路径、尺寸、方向”。iOS 相机直出的 JPG 可能带 EXIF 旋转信息，Android 部分机型返回的是 file:// 临时路径（H5 不可读），小程序则只返回 tempFilePath。
容易踩的坑：直接把 tempFilePath 当作永久路径保存；或用 uni.getImageInfo 同步获取宽高却没 catch 错误（比如 iOS 相册里 HEIC 格式会失败）。
- 统一用
uni.chooseImage（小程序）或uni.chooseMedia（iOS/Android 12+ 推荐，支持视频）获取原始资源 - 对返回的每个
tempFilePath立即调用uni.compressImage压缩并转为base64或上传后存 CDN URL，避免后续访问失效 - 需要预览/裁剪时，传入
sourceType: ['album', 'camera']并监听fail回调，区分错误类型：chooseImage:fail cancel是用户取消，chooseImage:fail no photos是相册为空 - 若需保留原图方向，压缩前先用
uni.getImageInfo拿orientation字段，再用 canvas 手动旋转（uni-app 的canvasAPI 在各端表现一致）
拖拽排序后如何持久化到本地或服务端？
排序本身只是 UI 层状态，不落盘等于白做。但直接每拖一次就 uni.setStorageSync 或发请求，既影响体验又可能丢序（比如快速连续拖拽未完成就切后台）。
更稳妥的做法是：只在用户明确提交（如点击「完成排序」按钮）或页面 onHide 时批量保存；同时内存中维护一份「待同步标记」，避免重复提交。
- 本地缓存用
uni.setStorageSync('photoOrder', JSON.stringify(orderIds))，key 名别用泛义词如list，加业务前缀防冲突 - 上传服务端时，不要只传新顺序数组，带上版本号或时间戳字段（如
sort_version: Date.now()），后端据此做乐观锁校验 - 如果支持多设备同步，客户端需在拉取相册列表时额外请求
/photos?sort_by=client_order，由服务端按客户端最新顺序返回数据，而非数据库默认 ID 排序
