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