uni-app中图片旋转应优先用canvas而非CSS transform，因transform仅用于预览，导出需操作像素；canvas需注意跨端差异、坐标系变换、裁剪同步及性能优化。
uni-app 中图片旋转用 canvas 还是 transform？
直接用 CSS transform: rotate() 无法真正改变图片像素数据，只适合预览；真要批量处理（比如导出旋转后的图），必须走 canvas。但注意：uni-app 的 canvas 在不同端行为不一致——H5 和微信小程序支持 2D 上下文，App 端（iOS/Android）需用 uni.createCanvasContext 且仅支持部分 API，ctx.rotate() 会绕画布原点转，不是绕图片中心，容易裁切错位。
实操建议：
- 先用
uni.getImageInfo获取原始宽高，避免压缩后失真 - 旋转前调用
ctx.translate(centerX, centerY)再rotate(radians)，否则图片会偏移出画布 - App 端若发现旋转后黑边或空白，大概率是没重置
ctx.setTransform(1,0,0,1,0,0)清除之前变换 - H5 端可直接用原生
HTMLCanvasElement，更稳定；小程序端务必用uni.createCanvasContext('id', this)绑定当前组件实例
裁剪区域怎么和旋转状态同步？
用户先旋转再裁剪，或边旋转边拖拽裁剪框，坐标系就变了。裁剪框的 left/top 是基于当前 canvas 坐标系的，而旋转后图像像素已重排，直接拿 DOM 位置去截取会错位。
关键做法是：把裁剪框四角坐标反向旋转回原始图像坐标系，再计算真实像素范围。
示例逻辑（简化）：
const rad = -rotation * Math.PI / 180; // 注意符号相反
const cos = Math.cos(rad);
const sin = Math.sin(rad);
// 假设 cropRect 是裁剪框在 canvas 上的 {x, y, width, height}
// 中心点相对于 canvas 原点偏移
const cx = cropRect.x + cropRect.width / 2;
const cy = cropRect.y + cropRect.height / 2;
// 反向旋转四个顶点（这里只算左上）
const x1 = (cropRect.x - cx) * cos + (cropRect.y - cy) * sin + cx;
const y1 = -(cropRect.x - cx) * sin + (cropRect.y - cy) * cos + cy;
// 最终得到原始图上的裁剪起点和尺寸（需再映射到原始分辨率）
常见错误：
- 忽略 canvas
scale缩放比（比如width设为屏幕宽度但实际 canvas 缓存是 2x 分辨率），导致坐标换算偏差 2 倍 - 没对齐图像原始宽高比，在旋转 90° 后仍按原
width × height截图，结果拉伸或留白 - 微信小程序中
canvasToTempFilePath的clip参数不支持旋转态下的动态裁剪，必须手动用drawImage把旋转后图像“画进”新 canvas 再截
批量处理多张图时内存和性能怎么扛住？
一次加载 10 张 4MB 的图，每张都创建 canvas、drawImage、rotate、getImageData……很容易触发 iOS WebView 内存警告或安卓低端机卡死。
必须做三件事：
- 用
uni.chooseImage({ count: 1 })分批选图，而不是一次性count: 9，控制单次处理量 - 每次 canvas 操作完立刻调用
ctx.clearActions()（App 端）或手动清空 canvas（ctx.clearRect(0,0,w,h)），避免指令队列堆积 - 导出前用
uni.getSystemInfoSync().platform区分平台：iOS 用quality: 0.6压缩，Android 可略高（0.8），H5 直接用canvas.toDataURL('image/jpeg', 0.7) - 不要在 for 循环里连续
await canvasToTempFilePath，改用Promise.all并限制并发数（如每次最多 3 个）
为什么裁剪后图片总带黑边或偏色？
黑边最常见原因是旋转后图像超出 canvas 边界，但没重设 canvas 宽高；偏色则多因 colorSpace 或 alpha 处理不当。
具体排查点：
-
canvas元素的width/height属性值必须显式设置为整数（不能是'100%'或auto），否则 H5 下默认 300×150，小图放大失真，大图被裁 - 旋转后图像外扩，新 canvas 尺寸应为：
Math.abs(w * cos) + Math.abs(h * sin)（宽）、Math.abs(w * sin) + Math.abs(h * cos)（高） - 微信小程序中，若原图含 alpha 通道（PNG 透明），
canvasToTempFilePath默认输出 JPG 会强制填充黑色背景；必须指定fileType: 'png'，或提前用ctx.fillStyle = '#fff'填白底 - App 端 iOS 使用
uni.canvasToTempFilePath时，destWidth/destHeight若非原图等比，会插值模糊——宁可前端用ctx.scale()缩放，也不要靠 API 自动缩放
旋转+裁剪不是简单叠加两个操作，而是坐标系、像素空间、设备渲染能力的三方博弈。最容易被忽略的是：每次 canvas 重绘前是否 reset transform，以及导出时有没有按平台特性切换格式与质量参数。
