网站无法上传图片

昨天下午，网站无法客户那边炸了锅。上传运营小妹连发十几条消息，图片截图里全是网站无法用户投诉——商品详情页的图片传不上去，后台一直转圈，上传最后蹦出一行红字：“上传失败，图片请稍后重试”。网站无法稍后了半小时，上传还是图片失败。

我远程登进服务器，网站无法第一反应是上传查磁盘空间。这是图片老毛病了，日志文件堆满硬盘，网站无法图片传不上去十有八九是上传这原因。df -h一看，图片果然，根分区用了98%。但清理完日志，再试，还是不行。这就怪了。

接着看Nginx错误日志，翻了几十行，发现一个反复出现的报错：client intended to send too large body。哦，原来是上传大小限制。默认配置才1M，现在手机拍的照片动辄5M、8M，能不失败吗？改掉client_max_body_size，设成20M，重启服务。心想这回总该好了吧。

结果，客户那边还是传不上去。这回连报错都没了，就是图片传完，页面不显示。我打开浏览器F12，盯着Network面板看请求。图片是传上去了，HTTP状态码200，但返回的数据里没有图片URL。再往前查，发现PHP脚本在处理上传时，有个move_uploaded_file函数，路径写的是相对路径。而服务器最近刚改了web目录的软链接，导致这个相对路径指向了一个不存在的目录。文件没移动成功，但脚本没报错，直接返回了成功。

这种静默失败最坑人。系统告诉你成功了，实际上啥也没干。我赶紧把路径改成绝对路径，再试，图片终于正常显示了。前后折腾了快两个小时，结果就是一个配置项加一个路径问题。

说实话，网站上传图片这种功能，看着简单，其实暗坑不少。磁盘、权限、大小限制、路径、文件类型校验，每个环节都可能出幺蛾子。而且很多问题不是立刻爆出来的，是等到某个条件触发才出现——比如用户换了个大图，或者目录结构调整了，才突然暴露。

我后来跟客户解释，他们听得半懂不懂，只问了一句：“那以后还会不会出问题？”我没办法打包票，只能把服务器配置重新梳理了一遍，把上传临时目录的权限、PHP的upload_max_filesize和post_max_size都调了一遍，还在代码里加了详细的错误日志——至少下次再出问题，能直接看到是哪一步挂了，不用再靠猜。

这事让我想起之前给一个小电商站做维护，也是图片上传问题。那个更邪门，只有特定几个用户传不上去，其他人都正常。查了半天，最后发现是那几个用户用的浏览器太老，不支持新的上传API，走的是回退方案，而回退方案的代码里有个变量名拼写错误。修好之后，那几个用户传图就顺了。

讲真，上传功能从来都不是“能传就行”那么简单。用户端的浏览器差异、网络环境，服务端的配置、存储策略，还有代码里的各种边界情况，任何一个点都能让这个看似基础的功能崩掉。而最麻烦的是，问题往往不是立刻显现的，它可能潜伏在某个角落，等着你哪次不小心踩上去。

今天这个案例算是运气好，路径问题还算好找。要是碰上那种偶发的、跟并发相关的上传失败，那才叫头疼。所以我现在的习惯是，凡是涉及文件上传的地方，测试时一定得用不同大小的文件、不同浏览器、不同网络环境都试一遍。哪怕麻烦点，也比客户半夜打电话来强。

很赞哦!（7）