直接用 img 标签无法裁剪因其是替换元素，不支持 overflow: hidden 和子元素定位；需转为 div 背景图或 canvas；background-size 选 cover 或 contain 取决于宽高比匹配与否；须用 pointerdown/pointermove/resize 事件精准控制交互；导出坐标必须换算至原始图片分辨率。
为什么直接用 img 标签做裁剪会失效
因为 <img> 是替换元素，不支持 overflow: hidden 和子元素定位，也无法响应鼠标拖拽裁剪区域。真正在编辑器里做实时裁剪，必须把图片转为 <div> 背景图或 <code><canvas></canvas> 绘制——前者轻量、兼容好；后者精度高、支持滤镜和像素操作。
background-size: cover 和 contain 的实际取舍
等比例缩放不是目的，而是裁剪的前提。用 cover 保证填满容器但会溢出，适合“选中局部”场景；用 contain 保证全图可见但留白，适合“缩略预览+放大拖拽”流程。关键点在于：二者都依赖父容器宽高比是否匹配原图——不匹配时，cover 必然裁边，contain 必然有空白。
- 若编辑器容器固定为
400px × 300px，而上传图是1200×800（宽高比 3:2），则cover刚好贴合无拉伸 - 若上传图是
800×1200（竖图），cover会裁掉上下各约 100px，这部分必须由 JS 记录裁剪偏移才能还原坐标 - 不要在 CSS 里写死
background-position，得用 JS 动态绑定mousemove和touchmove更新background-position值
裁剪框交互必须监听的三个底层事件
用户拖动裁剪框时，只靠 mousedown + mousemove 不够——移动端没 mousedown，缩放后坐标会漂移，窗口 resize 后位置错乱。真正要绑定的是：
-
pointerdown：统一处理鼠标/触屏起始，且能拿到clientX/clientY和pressure（可选压感） -
pointermove：配合setPointerCapture()防止移出容器后丢失事件流 -
resize事件（监听窗口或容器）：重新计算缩放比例和当前background-position的像素映射关系
漏掉 pointermove 的 capture，手指快速拖拽时裁剪框会“跳回原位”——这是移动端最常被忽略的卡点。
裁剪结果导出时坐标的单位陷阱
后端通常要接收 x, y, width, height 四个值，但它们必须基于原始图片分辨率，而不是编辑器容器尺寸。比如容器显示为 400×300，但图片原始是 4000×3000，那么缩放比例是 0.1，所有前端计算出的像素值都要乘以 10 再提交。
- 别用
getBoundingClientRect()直接取裁剪框位置——它返回的是相对视口的坐标，得减去图片容器的offsetLeft/offsetTop - 如果用了
transform: scale(0.5)缩放容器，更要先除以0.5再换算，否则坐标直接偏差一倍 - Canvas 方案下，务必用
ctx.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh)的前四个参数（源图像坐标）作为裁剪依据，而非 canvas 元素自身的宽高
坐标单位不统一，是前后端联调时最耗时间的隐性问题——它不会报错，只会让裁出来的图偏几像素或者完全错位。
