PHP 8.5 中 imagejpeg() 压缩质量参数不生效？

不是 PHP 8.5 的锅，是默认质量值被省略后触发了底层 libjpeg 的“无损模式”行为。PHP 8.5 没改这个逻辑，但旧代码在低版本里碰巧“看起来有效”，升级后就暴露了。

• imagejpeg($img, null, 80) 是安全写法，第三个参数必须显式传整数（0–100），不能省略或传 null
• 传 imagejpeg($img) 或 imagejpeg($img, null) 时，PHP 会调用 libjpeg 的 jpeg_set_defaults()，实际压缩质量可能接近 95+，远高于预期
• 如果上传后图片体积没变小，先检查是否漏传了质量参数——这是 90% 的“不压缩”问题根源

上传后用 imagecreatefromxxx() 重建图像再压缩，为什么反而变大了？

因为原始图可能是 WebP 或 PNG，自带 Alpha 通道或色度子采样；而 imagecreatefromjpeg() 强制转成 RGB 三通道位图，再用 imagejpeg() 输出，丢失了原始编码优势。

• 优先判断源格式：exif_imagetype($_FILES['file']['tmp_name']) 返回 IMAGETYPE_WEBP 就别硬转 JPEG
• WebP 图片直接用 imagecreatefromwebp() + imagewebp()，质量参数同样要显式传（如 imagewebp($img, null, 75)）
• PNG 若无透明需求，可先用 imagealphablending($img, false) 和 imagesavealpha($img, false) 关闭 alpha，再转 JPEG 省空间

PHP 8.5 的 gd_info() 显示 libjpeg 版本太低，影响压缩效果？

不影响质量参数解析，但老版本 libjpeg（如 6b）不支持渐进式 JPEG 和优化霍夫曼表，相同质量下体积大 15–25%，且无法启用 imageinterlace()。

PHP 8.5.12

修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。

下载

• 运行 php -r "print_r(gd_info()['JPEG Support']);" 确认开启；再查 gd_info()['JPEG Version']，低于 90（即 libjpeg 9.x）建议升级系统 GD 库
• Ubuntu/Debian 上：装 libjpeg-dev + 重新编译 PHP GD 扩展，或换用 apt install php-gd（新版源通常带 9d）
• 不要依赖 imageinterlace($img, true) 来“提升清晰度”——它只改变扫描顺序，对质量无实质影响，还可能让某些 CDN 缓存失效

上传路径中含中文或空格，move_uploaded_file() 后立刻用 GD 处理报错？

不是 GD 的问题，是临时文件路径被 URL 解码或 shell 转义污染了。PHP 8.5 对 $_FILES['file']['tmp_name'] 的校验更严格，非法字符会直接导致 imagecreatefromxxx() 返回 false。

立即学习“PHP免费学习笔记（深入）”；

• 永远用 is_uploaded_file($_FILES['file']['tmp_name']) 校验，再做后续操作
• 处理前先复制到安全路径：$safe_tmp = sys_get_temp_dir() . '/upload_' . uniqid() . '.tmp'; copy($_FILES['file']['tmp_name'], $safe_tmp);
• GD 函数只接受本地文件路径，不支持 php://input 或远程 URL；别试图绕过 move_uploaded_file() 直接读流

事情说清了就结束。最常被忽略的是：上传流程里混用不同图像格式的处理分支，又没统一关 alpha、没显式传质量值——这两点一错，压缩就形同虚设。