微信小程序前端需上传原始图及x、y、width、height四参数(基于原图尺寸),PHP后端校验坐标、处理EXIF旋转后用GD裁剪;推荐对象存储图片处理服务避免兼容问题。
小程序不能直接调用 PHP 的 GD 或 Imagick,得靠前端上传原始图 + 裁剪参数,后端接收后处理。关键不是“PHP 怎么裁”,而是“怎么把裁剪区域准确传过去”。
常见错误是只传 base64 或只传原图,漏掉 x、y、width、height 这 4 个坐标参数,导致后端无从下手。
wx.chooseImage 或 wx.chooseMedia 获取临时路径,再用 wx.uploadFile 上传到 PHP 接口formData 中带上裁剪参数:x、y、width、height(单位是 px,且基于原始图尺寸,不是 canvas 显示尺寸)scale 和 devicePixelRatio 会影响坐标计算,建议统一用 canvas.toTempFilePath 导出带缩放的图,并同步传入实际渲染宽高,后端按比例还原原始坐标GD 是最轻量的选择,但不支持 WebP 输入(PHP 8.1+ 才部分支持),也不支持保留 EXIF 旋转信息——用户竖拍的照片上传后可能横着裁。
getimagesize 拿到原始宽高,再用 exif_read_data 判断是否需要预旋转(重点看 Orientation 字段)x、y、width、height 是否越界,否则 imagecopyresampled 会返回 false 且不报错imagecreatefromxxx → 预旋转(如有)→ imagecreatetruecolor → imagecopyresampled → imageXXX 输出imagejpeg 而非 imagepng,除非明确需要透明通道;JPEG 更小,更适合小程序展示90% 是因为坐标没对齐原始图分辨率。小程序 canvas 渲染尺寸(比如 300×300)和图片原始尺寸(比如 1200×1600)不同,但裁剪参数必须基于原始图。
canvas.getImageData 或 canvas.getTransform 算不出真实坐标——得用 canvas.width/canvas.height 和图片原始宽高做比例换算$_POST['x'],要校验:if ($x $orig_w || $y + $height > $orig_h)
imagecopyresized 替代 imagecopyresampled,会出现锯齿和拉伸,尤其对人像失真明显自建 GD 流程容易踩坑,尤其并发高或要支持 WebP/AVIF 时。可考虑把裁剪逻辑外包出去,PHP 只做中转。
COS 的图片处理能力:上传后拼接 ?imageMogr2/crop/! 参数,例如 ?imageMogr2/crop/!400x300a100a50(宽×高@x@y)imageView2/1/w/400/h/300/q/90 + crop 参数,返回直链,PHP 不碰二进制move_uploaded_file 到临时目录,再 curl 上传到 COS/Qiniu,最后返回处理 URL真正难的不是写几行 imagecopyresampled,而是让前后端对“同一张图的同一个像素点”达成共识。坐标、DPR、EXIF、压缩质量——任何一个环节没对齐,裁出来就是错的。