一份巡检报告带着十几张现场照片，在弱网环境里传到八成突然断掉，如果客户端只能从头再传一遍，用户损失的不只是流量，还有耐心。断点续传解决的正是这类问题：让中断的传输从已确认的位置接着走，而不是归零重来。
原理：把一次传输拆成可确认的若干段
核心做法是把连续的字节流切成若干分片，每片独立上传，服务端按标识把片写入临时位置。客户端每收到一次成功确认，就把当前进度持久化下来；下一次启动时先向服务端询问哪些片已经到位，只补传缺失部分。要让这套机制真正可靠，有三个环节不能省。
一是进度记录的归属。只记在内存里没有意义，进程被杀、手机重启就丢了，必须落到本地存储，并与具体文件、具体用户绑定。
二是分片校验。每片传完做一次完整性校验，确认内容没有在传输途中损坏，否则拼接出来的文件是坏的，进度却显示完成。
三是幂等与清理。网络抖动会导致同一片被重复提交，服务端要能识别重复写入而不产生多余副本；长期未完成的上传会话需要有过期回收策略，否则临时空间会被残留数据占满。
它解决的是传输中断，不是内容冲突
这两件事经常被混为一谈。断点续传处理的是“数据在路上断了怎么办”，属于传输层问题；而两个人同时修改同一张工单、谁覆盖谁，属于业务层的冲突裁决，需要版本号、时间戳或字段级合并规则来处理。一个离线模块可以断点续传做得很扎实，冲突规则却依然粗糙，反过来也成立。评估方案时把它们分开看，才不会被“支持断点续传”这句话带偏。
什么场景真正需要
判断标准不在技术是否先进，而在传输单元的大小与网络的稳定程度。现场照片、签名图、PDF 报告这类附件，单个文件耗时长、失败概率高，重传成本最明显；批量离线录入的数据回传，条数多、集中在网络恢复瞬间发起，同样受益于分段提交与失败重试；多端协同中的增量同步和附件下发，则把断点续传用在了下行方向。
反过来，几个纯文本字段的提交，靠简单的失败重试就能覆盖，硬上分片机制只会增加调试面。功能该做多深，取决于离线期间用户到底要传什么、传多大、在什么网络条件下传——这几个问题没答清楚，报价区间再精确也只是估算。
