录音从采集到可用：把每个阶段记录清楚
区分正在录制、本地已保存、上传中与服务端可用，避免用一个进度条表达整个录音过程。
采集端先保证连续写入
录音程序从设备获取的是连续到来的音频数据。以 Windows 的音频采集接口为例，程序需要读取缓冲区中的数据，再及时释放已处理的缓冲区。界面绘制、网络波动或一次耗时计算，都不适合阻塞这条采集路径，否则可能来不及处理后续数据。
一种容易理解的设计是把采集和上传分开：采集阶段先持续写入本地文件，结束后完成文件收尾，再安排上传。对于较长录音，也可以分段保存，但需记录每段的顺序和时间信息。采用哪种方式，要结合磁盘容量、断电风险和需要的可恢复程度决定。
状态应对应实际证据
用户点击停止后，文件可能仍在写入尾部信息，因此停止采集和本地保存完成可以是两个状态。随后还有等待上传、上传中、服务端处理中和可用。失败状态则应保留发生在哪一步，便于判断是重新选择设备、恢复网络，还是重新尝试处理已有文件。
可以用一个短流程理解这些状态：采集中，接着是本地已保存，再到上传中，最后进入可用。只有服务端确认文件完整接收，并完成必要的格式与可读取性检查，才进入最后一步。播放列表应依据服务端确认的状态展示，不能只看本地进度条是否到达百分之百。
重试和清理相互配合
上传任务应有稳定标识。连接断开后先查询任务状态，再按接口约定续传或重传，避免同一段录音产生多个看起来不同的条目。服务端仍需执行文件类型、大小及权限检查。客户端生成的时长可以帮助展示，但实际可用性要结合接收文件的检查结果判断。
本地文件的清理时间也应明确。上传请求刚发出时就删除唯一副本，会让失败恢复失去依据；永久保留又会占满磁盘。可在服务端确认可用后，按约定保留一段时间再清理。界面同时展示录制状态、同步状态和异常原因，用户才知道当前可以关闭程序，还是需要处理未完成的任务。