直接用 form.submit() 上传文件易失败，因服务端需读完整个 multipart body 才能解析字段，大文件、长 boundary 或多隐藏字段易致静默截断；accept 仅前端提示，后端必须校验 magic number；应禁用原生提交，改用 fetch + formdata 分片上传，并设 keepalive、超时及稳定 boundary。
为什么直接用 form.submit() 上传文件容易失败
表单原生提交走的是 application/x-www-form-urlencoded 或 multipart/form-data 编码，但服务端日志采集、API网关或中间件常对字段结构、大小、超时有强约束。常见现象包括：req.files 为空但 req.body 有部分字段、Nginx 返回 413 却无明确日志、multer 报 Request aborted 但没堆栈。根本原因不是前端“没传”，而是服务端缓冲区被迫读完整个 multipart body 才能拆解字段——一旦文件大、boundary 长、隐藏字段多，就触发静默截断。
accept 属性只能提示，不能替代后端校验
accept 是浏览器级过滤提示，用户仍可手动切到“所有文件”并选中任意类型。它不阻止上传，也不影响请求体内容。生产环境必须同时做两件事：
- 前端用
accept=".csv,.xlsx,application/json"组合扩展名与 MIME 类型，提升兼容性 - 后端收到文件后，必须读取二进制头（如 Magic Number）判断真实类型，不能只信
Content-Type或后缀 - Node.js 中 multer 的
fileFilter函数必须显式cb(null, false)拒绝非法类型，否则默认放行
如何安全提取 <input type="file"> 的值并构造 FormData
浏览器禁止 JS 设置 input.files 或 value，但允许读取已选文件。关键陷阱在于：直接 new FormData(form) 会丢失空文件控件状态、忽略 disabled 字段、且无法注入 trace_id 等元数据。正确做法是手动遍历：
- 用
Array.from(input.files)转为数组，避免类数组对象陷阱 - 对每个
File对象，显式附加lastModified、size和type字段，避免后端解析歧义 - 若需携带额外字段（如
session_id），不要塞进FormData.append('session_id', ...)，而应统一用fetch发 JSON + 二进制混合体（即分块上传） - 禁用
enctype="multipart/form-data"的原生 form 提交，改用fetch+FormData显式控制
大文件上传必须设超时、keepalive 和分片逻辑
单次上传 >5MB 的文件，原生 fetch 容易因页面跳转、标签页休眠或网络抖动被中止。关键参数不能漏：
-
keepalive: true：确保页面卸载后请求仍继续发送 -
signal配合AbortController，设 30s 超时，避免阻塞主线程 - 不依赖单次请求完成整个文件：对 >10MB 文件，必须在前端按 2–5MB 分片，每片带
chunk_index和total_chunks，由后端合并 - Nginx 的
client_max_body_size必须 ≥ 单片大小 × 并发数 + boundary 开销（通常比原始文件大 5–10%）
最易被忽略的点：分片上传时，每个请求的 Content-Type 应为 multipart/form-data，但 boundary 必须稳定（不能每次随机），否则后端无法识别分片归属；同时，所有分片请求 header 中都得带上同一 X-Upload-ID，用于服务端关联和去重。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
