下午三点，网站运营部的上传小张把一份带产品图的报价单拖进后台，转了三圈菊花，附件页面弹出一行红字：“附件上传失败”。网站她试了四次，上传换了Chrome换Edge，附件压缩了图片再传，网站还是上传失败。最后她截图发到群里，附件配了句“这系统是网站不是又抽了”。这不是上传抽风，这是附件网站附件上传功能的设计缺陷——而且我敢说，八成以上的网站“上传失败”根本不是网络问题。

先看最容易被忽略的上传元凶：文件大小限制。很多后台默认2MB，附件但没人告诉用户。你传一个手机拍的3MB照片，系统直接拒绝，连个提示都不给——或者给个笼统的“上传失败”。我见过一个客户，传PDF合同传不上去，折腾半小时，最后发现限制是1MB，而那份合同扫描件有8MB。你说这能怪用户吗？限制值藏在系统设置第三级菜单里，普通用户根本找不到入口。

再说文件名。中文文件名、带空格、带括号，这些在Windows本地没问题，但服务器端如果用的老式Linux配置，编码不识别，直接拒绝写入。更隐蔽的是文件名里带了“#”或“%”，这类字符在URL解析时会被当成特殊符号，服务器直接返回400错误。你让用户改文件名？他不懂技术，只会觉得“这网站怎么这么烂”。

还有个场景特别常见：上传进度条走了一半突然卡住，然后报错。这多半是反向代理或负载均衡的超时设置太短。比如Nginx默认的proxy_read_timeout是60秒，如果文件上传速度慢，或者服务器处理慢，超过60秒连接就被切断。前端显示“上传失败”，后端日志里写着“upstream timed out”。这问题在视频或大文件上传时尤其明显，但很多开发只在本地用1MB的小图测试，根本没暴露。

还有一种情况更气人——浏览器插件捣乱。广告拦截插件有时候会误拦上传请求，尤其那些带“upload”关键词的脚本。我一个朋友在政府网站传材料，怎么传都失败，后来发现是AdBlock把那个上传接口当广告给屏蔽了。关掉插件，瞬间成功。这种问题排查起来最费劲，因为用户不会想到是插件问题，开发也难复现。

最后说个反直觉的：有时候“上传失败”是假象。文件其实传上去了，但后端回调没触发，前端没收到成功响应，就显示失败。用户刷新页面一看，附件根本不在列表里——这可能是数据库写入事务没提交，或者异步任务队列崩了。更糟的是，如果用户重复点击上传按钮，同一个文件被传了三次，服务器上存了三份，但前端只显示一份。这种bug最坑人，因为问题不在上传环节，而在状态同步。

所以，当你下次遇到“网站不能上传附件”，别急着怪网速。先看文件大小，把名字改成纯英文和数字，关掉所有浏览器插件，再试一次。如果还不行，打开浏览器开发者工具，切到Network标签，看那个红色请求的响应状态码——如果是413，就是文件太大；如果是403，可能是权限问题；如果是500，那纯粹是服务器代码写崩了。这些信息报给技术，他们能省一半排查时间。但大部分用户不会这么做，他们只会骂一句“破网站”，然后改用邮件发附件。这恰恰说明，上传功能的设计者，根本没从用户角度想过那些隐藏的坑。