layui 的 size 参数仅前端 kb 级校验，不阻止请求发送；413 是服务端（nginx/后端/cdn）拦截所致，需同步调整 nginx location 块 client_max_body_size、后端 multipart 限制及 cdn 配置，并通过 network 面板与 responsetext 组合判断真实拦截层。
Layui 的 size 参数根本拦不住 413，它只在前端做 KB 级校验，不发请求；真报 413，说明请求已发出并被 Nginx 或后端拒绝。
为什么 layui 设置了 size 还是报 413？
因为 size 是纯 JS 校验，单位是 KB，比如 size: 2048 表示文件 > 2MB 时，layui 直接不触发 upload 请求，连 before 都不会进。但只要文件 ≤ 2MB，请求就照发——此时若服务端限制更小（如 Nginx 默认 1MB），必然返回 413。
- 常见误操作：只改
size，没动 Nginx 或后端配置，用户传 1.9MB 文件仍失败 -
size建议设得比服务端上限略小（如后端允 50MB，前端设size: 48000），留出 form 字段、base64 头等额外开销 - 别信“前端校验够用了”，413 是服务端拦截，和 layui 无关
如何准确定位是 Nginx 拦的还是后端拦的？
浏览器 Network 面板里看真实状态码最可靠。但 error 回调里的 data.status 经常不准——尤其 Nginx 直接拦截时，data.status 往往是 0，而 data.responseText 里含 "Request Entity Too Large" 或 "Payload Too Large"。
- 正确判断逻辑应组合：
data.status === 413或data.status === 0 && data.readyState === 4 && /entity too large|payload too large/i.test(data.responseText) - 不要只依赖
data.status，否则会漏判 Nginx 层拦截 - 如果用 Cloudflare 或其他 CDN，也可能提前拦截并返回 413，响应体同样含关键词
Nginx 的 client_max_body_size 必须写在 location 块里
很多人在 http 或 server 块加了 client_max_body_size 100m，但依然 413——因为 layui 上传请求走的是你配的 url（比如 /api/upload），真正生效的是匹配该路径的 location 块。
- ✅ 正确写法：
location /api/upload { client_max_body_size 200m; } - ⚠️ 错误写法：只在
http块设，但location /或具体接口路径下没覆盖，仍用默认 1MB - 如果用 proxy_pass 转发，确保目标服务（如 Spring Boot）也同步放宽限制，否则 Nginx 放行了，后端照样 413
后端框架也要同步放开限制
即使 Nginx 放宽了，Spring Boot、Express、PHP-FPM 等仍可能各自设限，必须逐层检查。
- Spring Boot（2.x+）：
spring.servlet.multipart.max-file-size=50MB和max-request-size=50MB - Express + multer：
limits: { fileSize: 52428800 }（单位字节） - PHP：
upload_max_filesize和post_max_size都要调大，且post_max_size≥upload_max_filesize - 所有配置改完必须重启对应服务（Nginx reload 不等于后端重启）
真正麻烦的不是改哪一行，而是每一层都得对齐：前端提示值、Nginx client_max_body_size、后端 multipart 限制、临时目录权限、甚至 CDN 缓存策略——漏掉任意一环，用户点上传就卡住或弹“文件过大”，但实际根本没超你写的那个数。
