前端file.size检查仅是体验优化,必须在change事件中校验并清空input值;后端需同步配置nginx的client_max_body_size、框架limits.filesize及php的upload_max_filesize/post_max_size,三者数值须严格对齐,否则上传将静默失败或直接413。

前端 JavaScript 的 file.size 检查只是提示,不能替代后端硬限制;漏掉 Nginx 或框架层任一配置,上传就会静默失败或直接 413。
change 事件里读 file.size 是唯一可行的前端时机
用户点选文件后立刻校验,不是等表单 submit。否则一个 3GB 视频已挂载在 input 上,提交时才报错,体验崩坏。
-
file.size单位是字节,写5 * 1024 * 1024比5e6更直观、不易出错 - Safari 旧版或某些 WebView 可能返回
file.size === 0,必须加兜底:if (!file || !file.size) - 校验失败后一定要执行
e.target.value = '',否则重选同名文件不触发 change - 用
data-max-size="2097152"这类属性解耦配置,避免 JS 里硬编码
后端框架层必须设 limits.fileSize(如 multer)
Node.js + multer 场景下,只校验 req.file.size 或靠中间件手动 throw,根本拦不住超限请求——multer 在解析 multipart 时就已截断,req.file 根本不会存在。
- 正确做法是初始化 multer 实例时传
limits: { fileSize: 10 * 1024 * 1024 } - 这个值必须 ≤ Nginx 的
client_max_body_size,否则请求连 Node 进不去 - PHP 同理:
upload_max_filesize和post_max_size都要调,且后者 ≥ 前者
Nginx 的 client_max_body_size 是第一道网关
它卡在最外层,一旦超限,Nginx 直接返回 413,后端完全收不到请求体,前端 fetch 或 axios 会卡住几秒后报 network error,没有任何具体错误信息。
- 配置位置通常在
http、server或location块中,例如:client_max_body_size 20M; - 如果前端允许 10MB,Nginx 却只设了 5M,用户上传 7MB 文件时,前端无响应、后端无日志、Nginx error log 里只有一行 413 —— 最容易被忽略的断点
- Cloudflare、WAF 等中间件也可能有独立 body size 限制,需同步检查
真正难调的不是某一行代码,而是三处配置(前端 data-max-size、Nginx client_max_body_size、框架 limits.fileSize)必须数值对齐且逻辑一致。差 1 字节都可能让上传在某个环节悄无声息地消失。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











