图片上传到 100%，为什么还没发出去？

聊天里选一张图片，自己的窗口已经能看见，进度也走到 100%，对方却还没收到。这里至少有两次远端操作：上传文件，以及发送一条带文件引用的聊天消息。

项目的 Web 工作台把图片交给文件服务，再通过 XMPP 发出文件名、引用、类型和大小。浏览器里的 File 或 Blob 还可以直接用于本地预览，因此“我看得见”也可能发生在上传之前。

一个发送中状态，为什么不够用？

可以把整条流程显示成一个忙碌状态，但失败后就很难说明该从哪里恢复。拆开本地准备、文件上传和消息确认，才能保留各阶段已经取得的结果。

上传进度报告的是传输过程，100% 后还要等上传调用返回，确认拿到了可用引用；引用拿到以后，才构造聊天消息，再等待消息确认。接收端能否下载，又是之后的文件访问结果。

项目因此更新上传百分比时不直接把消息标为已发送。百分比消失、消息仍在等待，是可能出现的中间状态，界面需要能解释它现在是在上传还是等确认。

为了立即反馈，可以先创建占位消息，再在后台准备预览。项目当前的顺序则是先准备文件名、按条件生成缩略图，再创建本地 SENDING 消息。

这意味着选图后还可能停在前置处理，上传根本没开始。缩略图生成又位于后面主异常处理之外，前置失败未必能更新到同一条消息上，这部分反馈与重试入口仍需继续检查。

原始 File 会留在内存映射中；有缩略图时，还尝试把缩略图和原文件写入 Blob 存储。缓存失败会记录警告，后面仍继续发送，它不应直接等同于远端上传失败。

如果文件引用仍可用，可以复用它，只恢复后续消息发送。否则重复上传既浪费流量，也可能留下更多远端对象。

项目根据是否已有非空 URL 决定要不要上传。新上传路径拿到引用后写回消息，再检查连接、构造协议消息并等待确认；已有 URL 则跳过上传。

但跳过上传不会自动保持消息身份。重试仍要对应原消息、发送 ID 与确认目标，避免迟到结果改到另一条记录。当前也只检查 URL 字符串，没有验证对象是否仍存在或引用是否过期，失效后如何恢复还取决于文件服务。

本地准备失败时，消息可能尚未创建；上传失败时，需要保留原始文件；上传已成功但消息未确认时，应保留远端引用并先核对旧消息。消息已确认、只是接收端下载失败，则应恢复文件访问，而不是直接再发一条消息。

项目当前的主异常收尾还受“本轮是否需要上传”控制，已有 URL 的分支在确认前抛错时，未必与新上传分支同样更新失败状态。这是需要沿分支继续检查的地方。

如果文件已上传，消息最终没发成，远端也可能留下无关联文件，是否回收不能只从客户端确定。发送端可能一直在看本地缓存，要换一台设备访问远端引用才能检查接收端路径；刷新后预览消失，也不直接说明消息没发送成功。缓存 key 找预览，文件引用找内容，消息 ID 找发送结果，三者各自核对。