前端应在file input的change事件中用event.target.files[0].size校验文件大小，超限需清空value；后端须在Nginx、框架、语言层三重限制，且数值必须对齐；大文件必须分片上传并支持断点续传。
前端用 file.size 在 change 事件里拦最直接
用户点选文件后、提交前就得知道能不能传——等表单 submit 或 ajax 发出去再报错，体验已经毁了。核心就一句：event.target.files[0].size 返回字节数，拿它跟阈值比。
- 必须绑定在
input[type="file"]的change事件上，click或submit都晚了 - 校验后如果超限，一定要清空
e.target.value = ''，否则同名文件再点一次不会触发change - Safari iOS WebView 个别旧版本可能返回
file.size === 0，加个兜底判断if (!file || !file.size) -
accept属性只管类型，完全不控制大小，别混淆
后端得配三层：框架层、语言层、服务器层
前端限制只是提示，绕过太容易（禁 JS、curl 直发、改 DOM）。真正卡死靠后端三道关，漏一关就可能 413 或超时卡死。
- Node.js + Express：用
multer的limits.fileSize，比如{ fileSize: 50 * 1024 * 1024 } - PHP：改
php.ini里的upload_max_filesize和post_max_size，且后者必须 ≥ 前者 - Nginx：必须设
client_max_body_size 50M，否则请求根本到不了 PHP/Node，直接 413 - 关键点：Nginx 的
client_max_body_size必须 ≥ 后端框架允许的最大值，否则前端再严也没用
大文件（>100MB）别硬扛，得切片 + 断点续传
单次上传几百 MB，弱网下极易失败，重传成本高，还占满连接。分片不是“高级功能”，是必须项。
- 前端用
File.prototype.slice()拆块，每块 1–5MB，带唯一标识（如chunkIndex、totalChunks、fileId） - 服务端收到块后立即落盘（不要等全部收完），按序合并；失败时只重传缺失块
- 上传前先算文件
md5或spark-md5，调接口查是否已存在，支持秒传 - 别自己从零写分片逻辑，用
uppy或resumable.js，它们已处理好并发、重试、进度、取消
移动端和 WebView 容易忽略的兼容细节
安卓 WebView 和 iOS Safari 对大文件的处理差异不小，光看桌面 Chrome 是不够的。
立即学习“前端免费学习笔记（深入）”；
- iOS Safari 14.1+ 对
file.size支持稳定，但某些混合 App 内嵌 WebView 可能返回0，需 fallback 到服务端预检 - Android WebView（尤其旧版）对
input[type="file"]的multiple和大文件支持不一，建议单文件上传优先 - 微信内置浏览器对
accept过滤宽松，但对超限文件常静默失败，前端必须主动校验并提示 - 所有提示别只靠
alert()，移动端弹窗易被拦截，用页面内 toast 或 modal
实际最难的不是写哪一行代码，而是前后端限制数值没对齐——比如前端说 50MB，Nginx 卡在 10MB，用户上传到 9.8MB 时突然断连，连错误码都看不到。每次上线前，拿 curl 模拟超限请求，逐层验证响应是否一致。
