直接 composer require league/glide 后无法运行，因为 PHP-Glide 仅生成图片流而不提供 HTTP 服务层，需手动搭建接收 GET 请求、解析参数并调用 makeImage() 的入口脚本或框架路由，并正确配置 source 和 cache 路径及权限。
为什么直接 composer require league/glide 后跑不起来？
因为 PHP-Glide 本身不提供 HTTP 服务层，它只负责生成图片流；你得自己搭一个能接收 GET 请求、解析 width/height/fit 等参数、调用 Glide 生成响应的入口脚本。很多初学者卡在这一步——装完库就以为能直接访问 /img/photo.jpg?w=200，结果 404 或空白响应。
实际需要：一个可执行的 PHP 脚本（比如 glide.php）或框架路由（如 Laravel/ Slim），把请求参数映射到 GlideServer 实例的 makeImage() 方法。
- 必须手动设置
source（原始图目录）和cache（缩略图缓存目录），两者路径需真实存在且 Web 服务器有读写权限 -
cache目录若未设好，每次请求都重新生成，性能极差；若权限不对，会抛出League\Glide\Filesystem\CannotWriteFileException - 不要把
source设为 Web 可直接访问的路径（如./public/images），否则原始图可能被绕过 Glide 直接下载
如何安全暴露图片 URL 并防止恶意参数攻击？
PHP-Glide 默认允许任意 w, h, q 参数，但没做范围限制——攻击者可以传 ?w=9999999 触发内存溢出，或用 ?filt=unsharp&sigma=1000 拖慢服务。必须启用签名验证或白名单控制。
推荐做法是启用 SignatureFactory，所有合法 URL 都带 s=xxx 参数，服务端校验签名后再处理：
立即学习“PHP免费学习笔记（深入）”；
$server = ServerFactory::create([
'source' => 'path/to/source',
'cache' => 'path/to/cache',
'sign_key' => 'your-secret-key-here', // 必须保密，别硬编码在 web 目录
]);
- 生成带签名的 URL：用
$server->getImageUrl('photo.jpg', ['w' => 300, 'h' => 200])，它自动拼s=值 - 不启用签名时，至少用
setAllowedFilters(['brightness', 'contrast'])和setAllowedSize([100, 2000])限制参数范围 - 避免在 URL 中暴露原始文件名含路径（如
../etc/passwd.jpg），source的FilesystemAdapter默认已禁用路径遍历，但自定义 adapter 时要检查getPathPrefix()是否为空
Apache/Nginx 下如何让 /img/{path}.jpg?w=200 落到 glide.php？
Web 服务器默认按文件后缀找静态文件，不会把带查询参数的 JPG 请求转发给 PHP。必须配置重写规则，把所有 /img/* 请求交给 glide.php 处理，同时保留原始 $_GET 参数。
Apache（.htaccess）示例：
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^img/(.*)$ glide.php?path=$1 [QSA,L]
Nginx 示例：
location ^~ /img/ {
try_files $uri $uri/ /glide.php?path=$request_uri;
}
-
QSA（Query String Append）标志不能漏，否则?w=300&h=200会丢失 - Apache 中
$1是路径部分（如photo.jpg），Nginx 中$request_uri包含完整路径+查询参数，需在glide.php里用parse_url($_SERVER['QUERY_STRING'], PHP_URL_PATH)提取 - 别把
glide.php放在/img/目录下，否则可能形成循环重写
为什么缩略图生成后不生效，浏览器仍显示旧图？
常见原因是缓存策略没对齐：Glide 生成的图片 HTTP 响应头默认是 Cache-Control: public, must-revalidate, max-age=31536000（1年），但如果你改了源图或参数，CDN/浏览器可能还在用旧缓存。
- 开发阶段加
header('Cache-Control: no-cache, must-revalidate');临时禁用缓存 - 生产环境建议用「内容哈希」代替时间戳：把
photo.jpg改成photo.a1b2c3.jpg（哈希基于文件内容），这样源图一变 URL 就变，天然规避缓存问题 - 如果用了 CDN，确保它转发
Accept和Cookie头（虽然 Glide 不依赖它们），并设置缓存 key 包含全部查询参数（如/?w=300&h=200和/?w=300&h=201必须区分）
最易忽略的是 cache 目录权限和 SELinux 上下文（尤其 CentOS），即使 ls -l 看着可写，Apache 进程也可能因策略限制无法创建文件——查 getsebool httpd_can_network_connect 和 setsebool -P httpd_can_network_connect_db on。
