php网站文章图片问题

PHP网站文章里的图片，看起来只是上传和显示两件事，真做起来坑特别多。我见过不少站点，文章文字正常，图片一会儿裂开，一会儿缩略图变形，一会儿后台删了文章图片还留在服务器。问题往往不在PHP本身，而在配置、路径、权限和处理流程上。

最常见的是上传成功但前端不显示。打开浏览器控制台，图片请求404，多半是路径写错。有人数据库存的是/uploads/2025/06/abc.jpg，模板里却用相对路径，文章页在/article/123.html，浏览器会去/article/uploads/...找。改成以/开头，或者用完整域名，基本能解决。域名换过、从http升到https也会让旧图挂掉，因为数据库里还写着老域名。混合内容更隐蔽，https页面里加载http图片，浏览器直接拦掉，控制台会提示Mixed Content。

上传环节的限制也容易被忽略。PHP默认upload_max_filesize通常是2M，post_max_size是8M，很多虚拟主机不改。手机拍的原图动辄5M、10M，用户一传就失败。$_FILES里error等于1，表示超过upload_max_filesize；等于2是超过表单MAX_FILE_SIZE；等于3是只传了一部分；等于4是没选文件。别只看move_uploaded_file返回false，先把error打出来。多图上传还要看max_file_uploads，默认20，但总大小受post_max_size限制，超了$_POST和$_FILES都会空。

图片处理是另一个重灾区。用GD生成缩略图，大图容易把内存吃爆。一张5000×4000的JPEG，解压后按4字节一像素算就是80M，GD内部再复制、缩放，峰值轻松超过128M，于是白屏或500。稳妥做法是先getimagesize拿到宽高，超过限制就拒绝或分块缩小，再imagecreatefromjpeg。Imagick更省心，但服务器不一定装，而且policy.xml可能限制大图。手机照片还有EXIF方向问题，竖拍照片传到网页变横的。读exif_read_data的Orientation，按3、6、8旋转，或者用Imagick的autoOrient，能省很多客服。

文件名也别用中文和空格。Linux下能存，但URL编码、Nginx重写、浏览器兼容经常出岔子。最稳的是用md5或uniqid加随机数重命名，保留扩展名，按年月分目录。数据库只存相对路径，模板拼接域名。这样迁移、换CDN都方便。图片目录权限给755，文件644，别给777。上传目录还要禁止执行PHP，Nginx里加location ~* /uploads/.*\.php$ { deny all; }，否则有人传个图片马，后面就麻烦。

安全验证不能只看后缀。$_FILES[''type'']是浏览器给的，可以伪造。用finfo_file读真实MIME，再用getimagesize确认是图片。能二次渲染就二次渲染，比如重新保存为JPEG或WebP，木马代码基本被洗掉。图片格式上，WebP体积比JPEG小不少，同画质大概能省25%到35%，但老版本GD不一定支持，先function_exists(''imagewebp'')判断。AVIF更小，兼容性差一些。文章里大量图片，最好上传时生成几档尺寸，列表页用缩略图，详情页用大图，别直接甩原图。

编辑器粘贴图片也常出问题。有些富文本编辑器会把图片转成base64塞进文章内容，一条文章几MB，数据库迅速膨胀，查询和备份都变慢。正确做法是监听粘贴事件，把base64转成Blob，走上传接口，返回URL再插入。数据库存base64只适合极小图标，文章大图不要这么干。

排查图片问题，别急着重装程序。先看图片URL能不能直接打开，curl -I看返回200还是404、403。403多半是权限或防盗链，404是路径或重写，500是处理脚本报错。开PHP错误日志，看memory_limit、max_execution_time有没有超。CDN缓存也会骗人，换了图但URL没变，看到的是旧图，改文件名或刷新缓存。删除文章时记得同时删图片文件和缩略图，不然几年后服务器里全是没人引用的孤儿图。

把这些点顺一遍，PHP网站文章图片问题基本就那几类：传不上、存不对、显示不出、处理太慢、安全没防住。配置改对，路径统一，上传重命名，处理限尺寸，权限收紧，剩下就是日常看日志。