上周三下午，网站文件同事小陈在群里发了一条消息：“谁帮我看看，上传上传后台传个PDF死活传不上去，网站文件换了三个浏览器都不行。上传上传”配图是网站文件Chrome控制台里一行红色的413 Request Entity Too Large。这不是上传上传他第一次遇到，上个月传产品图也卡过一回，网站文件当时他以为是上传上传自己网络问题，重启了路由器，网站文件没用。上传上传

文件上传失败，网站文件绝大多数情况下跟你的上传上传网速、电脑配置、网站文件浏览器版本没太大关系。上传上传真正的网站文件问题往往藏在三个地方：服务器配置、前端代码、文件本身。小陈那个413错误，就是Nginx默认限制上传大小为1MB，他那个PDF有3.7MB，直接被挡在门外。改一行client_max_body_size 20m;再重启Nginx，问题消失。就这么简单，但不知道的人能折腾一下午。

还有一种更隐蔽的情况。前端用FormData提交文件，后端接口写的是multipart/form-data，看起来没问题。但如果你在请求头里手动设置了Content-Type: multipart/form-data，反而会丢掉boundary参数，后端解析不了，文件内容为空。这个坑我踩过两次，第一次查了两小时，第二次一眼就看出来了。浏览器控制台里看请求体，如果Content-Type后面没有boundary=----WebKitFormBoundary...这一串，基本就是这个问题。

文件本身也会导致上传失败。文件名里带中文、空格、特殊符号，比如产品图 #3 (最终版).png，某些老旧的服务器端脚本直接报错。还有文件大小写的问题，.JPG和.jpg在Linux服务器上是两个不同的东西，后端如果只允许小写扩展名，大写就传不上去。我见过一个后台，上传.jpeg可以，.jpg不行，因为白名单里只写了前者。这种细节没人会提前告诉你，只能一个个试。

浏览器这边也有坑。Chrome在某些版本下，如果页面是通过file://协议打开的，XMLHttpRequest上传文件会被CORS策略拦截。必须走http://localhost或者真实域名。Firefox相对宽松，但Safari对FormData的append顺序有要求，文件必须放在最后一个参数，否则后端拿不到。这些行为差异没有统一文档，全靠开发者自己踩。

服务端代码里，PHP的upload_max_filesize和post_max_size要同时改，只改一个没用。post_max_size必须大于upload_max_filesize，否则表单提交后$_FILES数组是空的，连错误信息都没有。Java Spring Boot的话，spring.servlet.multipart.max-file-size和max-request-size也要一起调。Node.js的multer中间件，默认没有大小限制，但如果你用了body-parser的json中间件在前，它会先把请求体吃掉，导致multer拿不到流。顺序错了，文件就丢了。

排查的时候别急着改代码。打开浏览器开发者工具，切到Network面板，找到那个上传请求，看三个东西：请求头里的Content-Length是多少，响应状态码是什么，响应体里有没有具体错误信息。413就是服务器限制，400可能是boundary丢了，500通常是后端代码异常。根据状态码去搜，比盲目试快得多。

小陈后来把Nginx配置改了，又发现后端PHP的upload_max_filesize还是默认的2M，接着改。前后不到十分钟。他跟我说：“早知道直接看控制台，省得我换浏览器。”我说你下次先看Network，别急着换环境。上传失败这事，九成以上都能从请求和响应里找到线索，剩下的那一成，是文件名里有中文空格。