Webman本身不内置图像处理能力，加水印必须依赖PHP的GD库（或Imagick），只要PHP环境启用gd扩展并支持JPEG/PNG，即可在控制器中调用imagecreatefromjpeg()等函数；需注意透明通道处理、字体路径、内存释放等细节。
Webman 本身不内置图像处理能力，加水印必须依赖 PHP 的 GD 库（或 Imagick），和是否用 Webman 框架无关——它只负责接收请求、分发逻辑，真正干活的还是 GD 函数。只要 PHP 环境启用了 gd 扩展，就能在 Webman 的控制器或服务类里直接调用 imagecreatefromjpeg() 等函数。
确认 GD 已启用且支持 PNG/JPEG
很多问题卡在这一步：Webman 运行时提示 Call to undefined function imagecreatefromjpeg()，实际是 GD 没开，或开了但禁用了某格式。
- 在 Webman 控制器中加一行：
var_dump(extension_loaded('gd') && gd_info()['jpeg_support'] && gd_info()['png_support']);，输出bool(true)才算过关 - 若为
false，别急着写水印逻辑——去 CLI 执行php -m | grep gd，再查php -r "print_r(gd_info());"看具体哪项为false - Webman 基于 Swoole，注意：Swoole 子进程继承父进程扩展状态，但某些 Docker 镜像（如
php:8.2-cli）默认不装libjpeg-dev和libpng-dev，编译 GD 时会 silently 跳过 JPEG/PNG 支持
图片水印叠加时透明区域变黑？
这是 PNG 水印最常踩的坑：水印图明明带透明背景，叠上去后透明部分成了纯黑或灰块。根本原因是 GD 默认关闭 alpha 通道混合。
- 必须对水印图资源单独设置：
imagealphablending($watermark, false)+imagesavealpha($watermark, true) - 注意顺序：这两句要在
imagecreatefrompng()之后、imagecopy()之前调用 - 如果原图也是 PNG 且需保留透明底，同样要对目标图（
$src）调用imagealphablending($src, false)和imagesavealpha($src, true) -
imagecopymerge()不尊重 alpha 通道，它只按百分比混合 RGB，透明度会被强行压平——除非你明确只要简单灰度融合，否则优先用imagecopy()
文字水印中文乱码或显示方块？
imagettftext() 渲染中文失败，90% 是字体路径或字体本身的问题，和 Webman 无关。
- 字体路径必须是绝对路径，例如
/var/www/fonts/simhei.ttf，不能用__DIR__ . '/../fonts/simhei.ttf'（Swoole Worker 工作目录可能不是你预期的） - 先用
file_exists($font_path)判断文件是否存在，避免静默失败 - 确认字体文件真实包含中文字符：Linux 下可用
fc-list :lang=zh查系统中文字体；Windows 下注意反斜杠要双写或用正斜杠 - 颜色要用
imagecolorallocatealpha()而非imagecolorallocate()，否则 alpha 值固定为 0（不透明），无法实现半透效果 - 字号太小（如
10）或抗锯齿开启状态下，某些中文字形可能被裁切，建议最小用12起步
Webman 中处理大图内存溢出或超时？
Webman 默认使用 Swoole HTTP Server，单次请求内存限制仍受 php.ini 的 memory_limit 约束，而 GD 处理 4K 图片极易突破 128M。
立即学习“PHP免费学习笔记（深入）”；
- 不要在控制器里直接加载并处理原始大图——先用
getimagesize()快速判断尺寸，超过阈值（如宽 > 2000）就拒绝或要求前端预缩放 - 若必须处理，改用
imagecreatefromstring(file_get_contents($path))避免多次磁盘读取，但更要紧的是调用imagedestroy()及时释放每一张中间图资源 - Swoole 的
worker_num设置过高 + GD 内存占用大，容易触发 OOM Killer；建议配合opcache.preload减少重复加载开销 - 生产环境强烈建议把耗时图像操作移到异步任务（如 Redis + TaskWorker），HTTP 请求只返回任务 ID，避免阻塞事件循环
imagecreatefromxxx() 调用都在真实分配显存级资源，漏掉一次 imagedestroy() 就可能让 Worker 在几小时内缓慢泄漏至崩溃。 
