413错误本质是Nginx拦截请求体，需同步调大Nginx的client_max_body_size（如50m）、后端框架对应限制（如Spring Boot的max-file-size）及网关配置，并确保H5端用FormData正确上传。
413错误本质是请求体被Nginx拦截，不是uni-app代码问题
遇到 413 Payload Too Large，第一反应不该改前端逻辑，而是确认请求是否根本没进后端。这个状态码由Nginx在入口层直接返回，后端服务日志里压根不会记录这次请求——你改 uni.uploadFile 参数、压缩图片、换 uni.request 手动上传，全无效。
必须同步检查并修改Nginx的client_max_body_size
绝大多数413都卡在这一步。Nginx默认只允许1MB请求体，而一张未压缩的手机照片就可能超5MB。
- 配置必须写在具体
location块里（比如location /api/upload），不能只丢在http块——后者容易被更细粒度的规则覆盖 - 数值按业务定：
client_max_body_size 50m足够应付高清图；视频类接口建议设200m或1g - 改完执行
nginx -t验证语法，再用nginx -s reload生效；仅重启项目或刷新页面毫无作用 - 注意磁盘临时路径：
client_body_temp_path指向的目录需有足够空间，且Nginx运行用户（如www-data）有读写权限，否则会转为500错误
后端服务限制也要对齐Nginx设置
Nginx放行后，请求才会到后端。如果后端框架自身有限制，照样会失败。
- Spring Boot：检查
spring.servlet.multipart.max-file-size和max-request-size，值必须 ≥ Nginx的client_max_body_size - PHP：确认
upload_max_filesize和post_max_size都调大，且post_max_size≥upload_max_filesize - Node.js（如Express + multer）：
limits: { fileSize: 50 * 1024 * 1024 }必须显式设置 - 微服务链路中，网关（如Spring Cloud Gateway）和业务服务两层都要查，漏一层就卡住
H5端上传失败常混入413假象，实际是Content-Type错乱
uni-app H5平台下，uni.uploadFile 传 filePath 会失效——它底层不走FormData，而是尝试把路径当文件发，导致服务端解析失败，部分Nginx配置（如严格MIME校验）可能因此触发413。
- H5必须先把图片转成
Blob或File对象，再用uni.request手动构造multipart/form-data - 关键点：
header不能手动设Content-Type，让浏览器自动生成带boundary的值，否则服务端无法解析 - 示例片段：
const formData = new FormData();<br>formData.append('file', fileBlob, 'photo.jpg'); // 第三个参数补上文件名，否则后端可能无后缀<br>uni.request({ url: '/api/upload', method: 'POST', data: formData });
真正卡住的往往不是某一行代码，而是Nginx配置改了但没reload、后端限制调小了、H5误传filePath——三者任一缺失，413就稳稳等着你。
