向日葵远程拷贝大文件中断后如何自动续传？

功能定位：断点续传到底解决什么

连锁门店、工厂上位机、高校机房都有一个共同痛点：运维人员通过向日葵远程控制把大文件（镜像、价签数据、设计稿）一次性推到几百台终端，一旦酒店 Wi-Fi 抖动或 4G 基站切换，传输窗口直接归零，只能人工重选文件再来一遍。2025Q4 之后，向日葵把「SRP-2.0 传输层」与「分片校验」打通，官方命名里虽无显眼"断点续传"四字，却借「文件分发」与「拖拽拷贝」两条通路，实现了中断后自动续传：已传分片本地落盘，重连后只补差异块。经验性观察，在 5% 丢包链路可把 2 GB 补丁的二次耗时压到原来的 15% 左右（样本为 20 条 100 Mbps 隧道）。

核心关键词向日葵远程拷贝大文件中断后如何自动续传，正是要回答：当进度条突然卡死，我们怎样让它"原地复活"而无需熬夜守机房。

与同类功能的边界：别把「分发」当「同步」

向日葵提供两条文件通路，各自续传逻辑不同：

1. 文件分发：主控端「设备列表」勾选 1–200 台终端 → 右键「文件分发」→ 上传至 Oray 边缘节点 → 各被控端后台 Agent 拉取。此通路支持秒级断点续传，因为节点会缓存完整包，终端重连后 HTTP Range 请求剩余字节。
2. 拖拽拷贝：远程窗口里直接把文件拖进目标目录，走 P2P UDP 隧道。此通路依赖双方本地分片缓存（Windows 下默认位于安装目录\Cache\Partial），重连后比对 SHA-1，只传缺失块。

经验性结论：前者适合「一对多、文件大、网络差」；后者适合「临时救急、双向互传」。若误把「分发」当「实时同步」，你会遇到"文件锁定无法即时回写"的尴尬——这是设计边界，不是 Bug。

决策树：先判断该不该续传

1. 中断后 ≤5 分钟且两端未重启 → 自动续传，无需人工干预。
2. 中断后 >5 分钟或任一端重启 → 检查缓存目录是否仍在；若缓存被清理，需重新上传。
3. 文件被第三方进程占用（如 SQL Server 写 MDF）→ 续传完成后仍会提示"替换失败"，需先停库。
4. 目标磁盘剩余空间 < 待补字节 → 续传前会弹窗阻止，避免半吊子文件。

一句话：缓存还在、空间足够、文件未被锁，就能续；否则果断重传更省时间。

操作路径：三端入口与最短点击

Windows 主控端

1. 打开向日葵控制台 →「设备列表」→ 勾选目标机 → 顶部工具栏「文件分发」。
2. 在弹窗里拖入大文件 → 右侧可见「若中断自动续传」复选框（默认勾选）→ 确认。
3. 上传中途若本地网络掉线，控制台「传输中心」会显红字"连接中断"；网络恢复后 30 s 内自动续传，进度条回到断点位置。

macOS 主控端

顶部菜单「工具」→「批量文件分发」；其余步骤与 Windows 一致，缓存路径为 ~/Library/Caches/Sunlogin/Partial。

Android/iOS 移动端

移动端暂不支持「文件分发」入口，只能远程桌面后点右下角「文件」图标进行拖拽拷贝；续传依赖被控端缓存，若被控为 Windows，则缓存仍在 PC 端，手机掉线重连后可继续。

日志排查：五类关键字定位失败根因

当自动续传未触发，先别急着重传；打开安装目录\Logs\transfer.log，按时间倒序搜：

• RangeNotSatisfiable → 边缘节点缓存被清理，需重新上传。
• SHA1Mismatch → 本地缓存块损坏，删除 Cache\Partial 对应文件夹后重试。
• DiskFull → 目标磁盘已满，清理空间后自动续传会立即继续。
• FileLocked → 目标文件被占用，需手动结束占用进程。
• AuthTokenExpired → 登录会话超过 24 h，重新输入账号密码即可。

例外与取舍：哪些场景必须人工重传

1. 目标文件中途被用户手动改名 → 续传索引失效，只能重传。
2. 公司组策略定时清理临时目录 → Cache\Partial 被清空，断点丢失。
3. 推送补丁后发现版本发错 → 即便能续传，也应主动取消，避免把错误文件补全。
4. 等保场景要求「传输完整性二次校验」→ 续传后仍需手动比对 MD5，不如直接重传一次来得合规。

一句话：当「续传」带来的风险大于时间收益，就果断放弃。

与第三方 Bot 的协同：最小权限原则

部分企业会把向日葵文件分发结果回写到内部工单系统。可复现做法：在被控端放置一个「第三方归档机器人」（自编脚本），监听 Cache\Partial 同级目录下的 transfer.done 标记文件；当检测到「done」且 exitCode=0 时，调用内网 API 回传 MD5。权限最小化：脚本仅授予「读取该目录 + 内网 API 写入」权限，不保存向日葵账号密码，避免泄露。

故障排查速查表

现象	最可能根因	验证动作	处置
进度条回到 0%	缓存目录被清空	查看 Cache\Partial 是否为空	重传；若组策略清理，可改路径到非系统盘
续传卡在 87% 不动	目标文件被锁	资源管理器尝试重命名该文件	结束占用进程或改推新文件名
日志报 403	账号并发超限	控制台「账号信息」看并发数	升级并发包或错峰推送

适用/不适用场景清单

高匹配场景

• 连锁门店凌晨批量下发 3 GB 价签库，1000 台设备，4G 网络。
• 高校机房周末推送 20 GB 的 CAD 镜像，机房总带宽 1 Gbps，允许中断后白天续传。
• 工业现场 PLC 调试包 500 MB，工程师用 iPad 通过热点接入，信号断续。

低匹配场景

• 金融券商柜台系统补丁，监管要求「断网后必须重新全量校验」，续传反而违规。
• 被控端磁盘剩余空间仅 5% 且无法扩容，续传可能写坏文件系统。
• 文件实时变动（如直播录制中的 TS 流），续传后内容不连续。

最佳实践 6 条

1. 推送前用「磁盘空间检测」脚本，确保剩余 > 待传文件 ×1.5。
2. 把缓存目录迁到非系统盘，避免重启被组策略清空。
3. 对 ≥5 GB 文件先压缩再传，减少分片数量，降低 SHA-1 比对开销。
4. 大批量推送用「文件分发」而非「拖拽拷贝」，可享边缘节点缓存。
5. 凌晨窗口期提前 30 分钟启动，若中断仍有整晚时间续传。
6. 传输完成后再拉一次 MD5 清单，与本地比对，确保合规审计。

验证与观测方法

想量化续传效果，可在主控端「传输中心」导出 CSV，字段包含：任务 ID、文件大小、已传大小、耗时、平均速率。对比「中断后重传」与「中断后续传」两行数据，计算「时间节省比 = 1 – 续传耗时 / 重传耗时」。经验性观察：在 100 Mbps、5% 丢包链路，该比值集中在 0.8–0.9 区间，即可向领导交差。

版本差异与迁移建议

截至当前的最新版本（Windows 10.12）已统一续传逻辑；若你仍停留在 9.x，路径为「高级设置」→「传输优化」→「启用断点续传」，且不支持边缘节点缓存，建议升级。升级前把 Cache\Partial 整个备份，安装程序会继承旧缓存，避免正在进行的任务归零。

FAQ：你可能还关心这些

收尾：下一步行动清单

读完本文，你只需做四件事即可把「断点续传」真正落地：

1. 把向日葵升级到截至当前的最新版本，确认「传输中心」已出现「若中断自动续传」复选框。
2. 将缓存目录迁到非系统盘，并在组策略里排除该路径。
3. 今晚找一条 4G 热点，模拟 5% 丢包，把 1 GB 补丁推到测试机，记录「重传/续传」耗时，向团队证明价值。
4. 把本文的「日志关键字速查表」贴到运维 Wiki，下次夜班同事掉线时，5 分钟内就能定位根因。

做到以上四点，你就能在老板问起"为什么别人加班你睡觉"时，把自动续传的 CSV 报告甩给他——数字不会撒谎，向日葵已经帮你把夜班续上了。