PHP服务端需拦截/thumb/尺寸/路径请求，校验参数与原图路径，检查缓存；未命中则用GD缩放生成并落盘，设置正确Content-Type和Cache-Control头，防止目录穿越与内存溢出。
PHP 服务端如何响应懒加载请求并生成缩略图
直接判断：不是前端加 loading="lazy" 就算懒加载完成，后端必须配合按需生成、缓存和正确响应。否则图片仍会全量下载，带宽没省，还多了一次 HTTP 请求。
核心逻辑是拦截形如 /thumb/123x456/path/to/image.jpg 的请求，解析尺寸与原图路径，检查缓存是否存在；不存在则用 imagecreatefromjpeg 等函数解码、缩放、保存，再输出给浏览器。
- 必须校验原图路径，防止目录穿越（比如过滤掉
../和绝对路径） - 缩放前先用
getimagesize检查原始尺寸，避免放大失真或内存溢出 - 生成后务必设置正确的
Content-Type（如image/jpeg），否则浏览器可能不渲染 - 建议用
file_exists+is_file双重判断缓存文件，避免竞态导致重复生成
为什么不能用 GD 直接输出而不写入磁盘
看似省 IO，实则容易拖垮 PHP 进程：GD 处理大图（比如 5MB 原图）时内存占用常超 100MB，且无法复用；而写入磁盘后，Nginx/Apache 可直接 sendfile 返回，PHP 进程秒退。
更关键的是——没有落盘就无法被 CDN 或反向代理缓存，每次请求都得重跑 PHP，带宽没省，CPU 先爆。
立即学习“PHP免费学习笔记（深入）”；
- 缩略图路径建议按哈希组织，例如
/cache/thumb/{md5(src.'-w-h')}.jpg，避免单目录文件过多 - 生成失败时返回 404 或 400，并带上简短错误信息（如
"invalid dimension"），方便前端降级 - 不要在缩略图生成逻辑里调用
sleep()或usleep()控制频率，应由 Nginx 的limit_req模块统一限流
常见 500 错误和 GD 扩展缺失怎么办
最典型的现象是访问缩略图 URL 直接报 500，但错误日志里只显示 "PHP Fatal error: Uncaught Error: Call to undefined function imagecreatefromjpeg()" —— 这说明 GD 扩展根本没启用。
验证方式很简单：运行 php -m | grep gd，无输出即未启用；或者访问 phpinfo() 页面搜 gd。
- Debian/Ubuntu 下装扩展：执行
sudo apt install php-gd，然后重启php-fpm或 Apache - Alpine 容器中：用
apk add php7-gd（注意版本号匹配） - 即使启用了 GD，
imagecreatefromwebp也可能不可用——WebP 支持需 PHP ≥ 7.4 且编译时开启--with-webp-dir - 别依赖
extension=gd.so写在php.ini里就万事大吉，某些环境（如 Docker）要确认 ini 文件实际被加载（看php --ini输出）
怎么让缩略图真正“按需”而不是预生成一堆
真正的按需 = 用户第一次请求某尺寸时才生成，后续全走缓存。很多人误以为要 cron 预扫目录生成所有尺寸，这反而浪费磁盘和时间。
关键在于 URL 设计和 Web 服务器配置：让所有缩略图请求都落到同一个 PHP 脚本（如 thumb.php），由它解析路径参数，而不是靠文件系统真实存在来路由。
- Nginx 示例规则：
location ^~ /thumb/(\d+)x(\d+)/(.+\.(jpe?g|png|webp))$ { try_files $uri @thumb; }，再配location @thumb { fastcgi_pass ...; } - Apache 用
RewriteRule ^/thumb/(\d+)x(\d+)/(.+\.(jpe?g|png|webp))$ thumb.php?w=$1&h=$2&src=$3 [L,QSA] - 务必对
w和h参数做数值校验（如filter_var($w, FILTER_VALIDATE_INT, ['min_range'=>1, 'max_range'=>4096])），防恶意传入极大值耗尽内存 - 缩略图命名里不要包含用户可控字符串（如原始文件名），否则易被构造为
../../../etc/passwd.jpg绕过路径校验
最易被忽略的点：缩略图缓存头。哪怕文件已存在，如果 PHP 脚本没输出 Cache-Control: public, max-age=31536000，CDN 和浏览器都不会长期缓存，等于白做。
