PHP GD库图像处理需严格匹配格式函数、启用alpha支持、使用绝对路径字体、动态计算坐标并及时销毁资源，否则必现模糊、乱码或内存溢出。
PHP 自带的 GD 库能完成图像缩放和水印添加，但直接调用 imagecopyresampled() 或叠加文字/图片水印时，容易出现模糊、偏移、透明丢失、中文乱码或内存溢出——这些问题不是配置不对，而是没处理好图像资源类型、色彩空间和坐标对齐。
缩放前必须判断原始图像类型并正确创建资源
GD 不支持直接从路径读取所有格式，imagecreatefromjpeg() 无法读 PNG，imagecreatefrompng() 会把 GIF 的动画帧当静态图处理。更关键的是：用 getimagesize() 获取类型后，必须匹配对应创建函数，否则返回 FALSE 导致后续全崩。
实操建议：
- 用
pathinfo($file, PATHINFO_EXTENSION)获取后缀，统一转小写后映射到imagecreatefromjpeg/imagecreatefrompng/imagecreatefromgif - PNG 和 GIF 必须在创建后立即调用
imagealphablending($img, false)和imagesavealpha($img, true)，否则透明通道会被丢弃 - 缩放目标尺寸建议用整数计算，避免浮点导致
imagecopyresampled()坐标错位
文字水印中文显示异常的三个硬性条件
GD 的 imagettftext() 显示中文失败，90% 情况不是字体路径错了，而是缺了三样东西：字体文件本身含中文字符集、PHP 启用了 freetype 支持、调用时指定了绝对路径且文件可读。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 用
gd_info()检查FreeType Support是否为true，否则换系统或重编译 PHP - 字体路径不能是相对路径（如
./simhei.ttf），必须用__DIR__ . '/simhei.ttf'这类绝对路径 - 字号不能小于 12，
imagettftext()对小字号中文渲染极差；起始坐标$x和$y是文字基线位置，不是左上角，需手动加偏移（如$y += 10）才对齐
图片水印叠加时透明度与位置偏移的控制逻辑
用 imagecopy() 或 imagecopymerge() 叠加水印图，常见问题是水印发虚、边缘生硬或位置总偏右下——根源在于源图和水印图的 alpha 处理不一致，以及未考虑水印图自身的尺寸边界。
实操建议：
- 水印图也必须用对应函数加载，并执行
imagealphablending($watermark, false)+imagesavealpha($watermark, true) - 用
imagesx()/imagesy()动态算水印坐标，例如右下角：$dst_x = $src_w - $water_w - 10，别写死像素值 - 优先用
imagecopy()（非 merge），它保留完整 alpha；imagecopymerge()的$pct参数只控制整体不透明度，无法做局部混合
缩放+水印组合操作的内存与顺序陷阱
一次操作里先缩放再加水印，看似合理，但若原图大（如 5000×3000）、缩放比例又小（如缩到 800×600），中间生成的缩略图资源仍占大量内存；更危险的是：如果在缩放后没销毁原始图像资源（imagedestroy($original)），PHP 可能因内存超限直接 500。
实操建议：
- 缩放完成后立刻
imagedestroy($original)，再加载水印图，避免两份大图同时驻留内存 - 水印图尽量用小尺寸（如 200×80），加载后也应检查
imagesx($watermark) > $dst_w * 0.3，过大就先缩放水印自身 - 最终输出前统一用
header('Content-Type: image/jpeg')并调imagejpeg($final, null, 90)，质量设 90 是清晰度与体积的合理平衡点
GD 处理图像没有“自动适配”这回事：每个 imagecreatefromxxx 函数的行为差异、每种格式对 alpha 的要求、文字坐标系的基线逻辑、资源销毁时机——漏掉任意一个，结果就不可控。真正卡住人的从来不是代码行数，而是这些藏在文档角落的刚性约束。
