HTML5上传前限制文件大小需在input的change事件中用JavaScript读取file.size判断，accept属性仅限类型无法限制大小；后端必须校验，因前端限制可被绕过。
HTML5 上传前如何限制文件大小（
）
HTML5 本身不提供原生的「服务端式」上传大小拦截，但可以通过
元素的
属性配合 JavaScript 的
API，在用户选择文件后、提交前立刻检查大小，避免无效上传。这是最常用且必须的第一道防线。
属性只过滤文件类型（如
），**完全不能限制大小**，别被误导
真正起作用的是读取
（单位是字节）
必须在
事件中检查，不能等到表单
才做——否则用户可能已选中数 GB 视频却毫无提示
注意：Safari 旧版本（≤14.1）对
对象的
支持稳定，但某些 iOS WebView 可能返回
；建议加兜底判断
后端必须校验：为什么
前端
限制只是“友好提示”
前端限制可被绕过（禁用 JS、修改 DOM、用 curl 直传），所以服务端校验是强制要求。不同后端环境的配置点差异大，但核心逻辑一致：拒绝接收超过阈值的请求体。
Node.
js
+ Express：需配合
中间件的
选项，而非仅靠
PHP：检查
并与
、
ini 设置比对
Nginx：设置
，否则请求根本到不了后端，直接返回 413 Request Entity Too Large
注意：Nginx 的
必须 ≥ 后端框架允许的最大值，否则前端限制再严也无意义
常见错误：表单提交后才发现 413 或超时
这不是代码写错了，而是前后端限制没对齐或缺少中间层反馈。典型表现是用户点上传后页面卡住几秒，最后跳 413 或白屏。
前端没监听
的
，只靠后端报错，体验极差
后端返回 413 时没配好 Nginx 的
，导致用户看到默认 Nginx 错误页，而非友好提示
使用 AJAX 上传时，没处理
的早期失败（比如服务端中途断连），误以为是网络问题
移动端 WebView（尤其 Android 低版本）可能不触发
事件，建议加按钮点击触发
模拟，并监听
和
双事件
进阶方案：分片上传 + 前端哈希校验（大文件场景）
当业务明确需要支持 >100MB 文件时，单纯限制大小已不够，得换架构。此时重点不是“设上限”，而是“可控上传”。
立即学习
“
前端免费学习笔记（深入）
”；
用
分块读取，每块控制在 2–5MB，规避单次请求超限
上传前用
+
算哈希，实现秒传（服务端先查哈希是否存在）
服务端需支持接收分片、合并、校验完整文件大小（比如合并后
文件再比对）
注意：Safari 对
返回的
类型处理有兼容性问题，建议统一用
包一层
真正的难点不在“怎么设大小”，而在“用户选了 2GB 文件却以为马上能传完”——这时候前端限制只是止痛药，分片才是手术刀。
input[type="file"]inputacceptfilesacceptaccept="image/*"event.target.files[0].sizechangesubmitfilessize0if (!file || !file.size)document.getElementById('upload').addEventListener('change', function(e) {
const file = e.target.files[0];
if (!file) return;
const maxSize = 5 * 1024 * 1024; // 5MB
if (file.size > maxSize) {
alert(`文件不能超过 ${maxSize / 1024 / 1024}MB`);
e.target.value = ''; // 清空 input，否则重复触发 change 时不会再次触发
}
});multerlimits.fileSizereq.headers['content-length']$_SERVER['CONTENT_LENGTH']upload_max_filesizepost_max_sizeclient_max_body_size 10M;client_max_body_sizeinput[type="file"]changeerror_page 413XMLHttpRequest.upload.onprogresschangeclick()inputchangeFile.prototype.slice()FileReaderSparkMD5statBlob.slice()Blobnew Blob([blob], {type: blob.type})