需求一句话："让用户把文件丢进对话框，AI 读完能答。"听着简单。真做下来，从"用户松手"到"AI 开始答"中间，前端要管的环节比我预想的多一截。这篇把整条链路拆开讲，谁要做类似的多模态上传，照着排查能省不少时间。
整条链路长这样
我画一下，免得只见树木：
用户给文件（点选 / 拖拽 / 粘贴）
→ 前端校验（类型、大小、数量）
→ 取文件（大文件分片）
→ 上传带进度
→ 后端落存储 + 触发解析
→ 前端轮询/订阅解析状态
→ 解析完，文件作为上下文进对话
前端要扛的是第一段到倒数第二段。一段一段说我踩的坑。
1. 三种入口，逻辑别写三遍
点选、拖拽、粘贴板（Ctrl+V 贴图）是三个事件源，但后面该跑的校验和上传是同一套。我第一版傻乎乎写了三份，改个大小限制要改三处。后来抽成一个 handleFiles(fileList)，三个入口只负责把文件喂进来。粘贴这条尤其容易漏，很多人只做了点选和拖拽。
2. 校验要在"取文件之前"
类型、大小、数量限制，必须在真正读文件 / 发请求之前拦。我有一版把校验放到上传中间件里，结果一个 200MB 的视频已经开始分片了才被拒，用户白等。前移之后体验顺多了。
顺嘴提一个真实数字：我们限单文件 50MB、一次最多 5 个，是看了三周日志里 99 分位的文件大小定的，不是拍脑袋。
3. 大文件分片 + 断点续传
超过阈值（我设的 10MB）就切片传。切片的好处不只是绕过单请求体积限制，更是断了能续——移动端网络抖一下，整个大文件重传用户能气死。我用 file.slice 切，每片带 chunkIndex 和文件 hash，后端按 hash 去重，秒传同一个文件也顺手做了。
4. 上传完 ≠ 能问，中间还有"解析中"
这步最容易被忽略。文件传上去了，后端要解析（PDF 抽文本、图片走识别），这有个耗时。前端得有个明确的"解析中"状态，别让用户文件刚传完就发问，结果 AI 说"我还没看到内容"。我用一个小状态机管：uploading → parsing → ready → failed，UI 上对应进度条、转圈、可发问、重试。
一个还在纠结的取舍
解析状态我现在是前端轮询拿的，简单但有延迟，文件大时用户盯着"解析中"会嘀咕。想换成服务端推，但要多维护一条通道，对这个量级有点重。暂时轮询凑合，间隔做了递增退避。你们这种状态是轮询还是推？
模型和文件理解的能力我没自己搭，多模态解析和模型调用直接接的讯飞 MaaS 现成 API，前端只负责把这条上传—解析—进上下文的链路缝顺，模型那端按调用计费，省了自建解析服务的功夫。
做多模态上传，体验的分水岭就在那些"中间态"做没做。你们的上传链路在哪一环最容易出幺蛾子？评论区聊聊 👇
