移动端图片卡顿主因是HTTP请求阻塞与资源过大，需设Cache-Control+ETag、按DPR/viewport生成适配尺寸WebP缩略图，并将图片服务剥离至CDN/对象存储。
移动端图片加载卡顿，本质是 HTTP 请求阻塞与资源体积过大
PHP 本身不直接渲染图片，但常通过 readfile()、imagejpeg() 或 Nginx/Apache 的动态路由（如 /api/image.php?id=123）输出图片。这类接口若未正确设置缓存头、未压缩、未适配设备分辨率，就会导致移动端反复请求、解码慢、首屏延迟——不是 PHP 执行慢，而是浏览器没复用缓存，或下载了远超屏幕所需的高清图。
必须设置 Cache-Control 和 ETag，否则每次都是 200 而非 304
PHP 动态生成图片时，默认无缓存响应头，浏览器无法复用。即使内容不变，也会重复下载。关键不是「加缓存」，而是「加对缓存」：
-
Cache-Control: public, max-age=86400（静态化图片可设 1 天；若图片可能更新，改用max-age=3600+ETag） - 务必配合
ETag：用图片内容哈希（如md5_file($path)）或数据库中记录的 version 字段生成，避免时间戳类弱 ETag - 禁用
Expires（HTTP/1.1 已过时），优先用Cache-Control - 如果用 CDN（如 Cloudflare、腾讯云 CDN），确保其未覆盖或忽略你设的
Cache-Control
示例片段：
header('Cache-Control: public, max-age=3600');
header('ETag: "' . md5_file($real_path) . '"');
header('Content-Type: image/jpeg');
readfile($real_path);
PHP 生成缩略图必须按设备 DPR 和 viewport 宽度裁切，不能只靠前端 <img srcset>
移动端网络差、CPU 弱，浏览器下载 2000px 宽原图再缩放显示，既浪费带宽又触发 JS 解码卡顿。PHP 后端需主动识别设备能力并输出合适尺寸：
Android Remote Control
下载
远程控制 Android 设备，支持截图、自动化操作手机 App 等功能。本应用使用 uiautomator2 作为底层框架，通过 ADB 连接设备，用户无需 Root（1）查看手机屏幕；（2）自动化操作手机 App；（3）远程安装/卸载应用……
立即学习“PHP免费学习笔记（深入）”；
- 从
$_SERVER['HTTP_USER_AGENT']或更可靠的$_GET['w']/$_GET['dpr']（由前端 JS 检测后拼入 URL）获取目标宽度与设备像素比 - 用
getimagesize()+imagecreatefromjpeg()+imagecopyresampled()生成对应尺寸，而非简单imagecopyresized()（质量差） - 强制开启 WebP 支持：
imagewebp()+header('Content-Type: image/webp')，Android Chrome/iOS Safari 均已支持，体积比 JPEG 小 25%~35% - 避免在循环中反复调用 GD 函数处理同一张图；加文件级缓存（如
/cache/thumb_123_w400_dpr2.webp）
CDN + 图片服务分离是必选项，PHP 不该承担高并发图片 IO
当并发请求超过 50+/秒，PHP-FPM 进程会排队读磁盘、开 GD、输出二进制，CPU 和 I/O 瓶颈立刻暴露。此时优化代码意义不大，架构上必须剥离：
- 把原始图上传到对象存储（如 OSS、S3），PHP 只写元数据；访问时由 CDN 回源到对象存储，或通过 CDN 的图片处理参数（如阿里云
?x-oss-process=image/resize,w_400）实时生成 - 若必须用 PHP 中转，至少用
fpassthru()替代readfile()，减少内存拷贝；且关闭 output buffering（ob_end_clean()） - Nginx 层加
expires 1h和add_header Vary "Accept"（为 WebP 兼容） - 检查是否启用了
mod_deflate或gzip—— 对图片无效，反而增加 CPU 开销，应禁用
真正卡顿的根源，往往藏在「以为 PHP 在干活」的错觉里：它只是管道，而管道两端（存储、CDN、客户端）没对齐，再调优也白搭。
