关键是修改Nginx的client_max_body_size参数：在server或location块中设为10m–100m（依图片类型而定），确保作用域精准匹配上传路径，并同步调高后端及前端限制，最后重载配置并端到端验证。
要避免大宗商品图片上传时出现 413 Request Entity Too Large 错误，关键在于合理调大 Nginx 的 client_max_body_size 指令，并确保该配置在正确的作用域生效。
确认当前限制值
默认情况下，Nginx 的 client_max_body_size 是 1m（1MB）。大宗商品平台常需上传高清实物图、多角度扫描图或带元数据的 TIFF/PNG 文件，单张可能达 5–20MB。若未显式配置，上传超限即触发 413。
- 检查配置：运行
nginx -T 2>/dev/null | grep client_max_body_size查看全局/HTTP/server/location 各层级实际生效值 - 注意优先级：location 块中的设置会覆盖 server 块，server 块覆盖 http 块；上传接口路径（如
/api/v1/upload）必须被匹配到才生效
按业务场景设合理上限
不建议盲目设为 0（无限制），存在安全与资源风险。应结合典型上传行为设定略高于峰值的值：
- 普通商品图：建议设为
10m（支持 4K JPEG/PNG） - 含高精度光谱、三维点云或 PDF 报告的复合上传：可设为
50m - 仅限后台管理端的大宗样品图集批量上传：可在对应 location 中设为
100m，但需配合鉴权与速率限制
确保配置作用域精准匹配上传路径
常见错误是把 client_max_body_size 写在 http 或 server 块却未覆盖到实际上传 endpoint。例如 API 网关前置了其他代理，或前端用 /upload 路径而 Nginx 配置只写了 /api：
- 推荐写法：
location ^~ /upload {
client_max_body_size 50m;
proxy_pass http://backend;
} - 避免使用正则 location（如
~ \.php$）匹配上传接口，因正则优先级低于前缀匹配，易导致配置失效 - 若用 OpenResty 或 Lua 处理上传，还需检查
lua_socket_read_timeout和缓冲区设置是否协同
验证与联调要点
改完配置后不能只 reload 就结束，需端到端验证：
- 用
curl -X POST -F "file=@large.jpg" https://your-domain.com/upload模拟真实上传 - 查看 Nginx error.log 是否仍有
client intended to send too large body日志 - 检查后端服务（如 Spring Boot）自身是否有
spring.servlet.multipart.max-file-size等二次限制，需同步放宽 - 前端上传组件（如 Ant Design Upload、Element Plus）也要确认其
maxSize参数与后端一致，避免前端拦截掩盖真实问题
