Windows批处理无真正断点续传：robocopy /Z仅支持网络会话内重连，不跨进程持久化；可靠方案是PowerShell+BITS或WSL2+rsync，需手动管理状态与锁机制。
断点续传在批处理里根本不存在
windows 原生 copy、robocopy 都不支持“中断后从上次位置继续写入文件”——这不是配置问题，是协议和文件系统层面的限制。所谓“续传”，本质是比对已传输部分与源文件差异，而批处理没有内置哈希校验、分块记录、状态持久化能力。
常见错误现象：robocopy /Z 被误认为能续传大文件；实际它只对网络中断时的**单次传输会话**有效（即连接断了重连后继续传当前文件），一旦脚本退出或任务计划程序终止，进度就丢失。
-
robocopy /Z仅适用于 SMB 网络复制，本地磁盘或 FTP/HTTP 不生效 - 断电、强制关机、任务计划程序“停止任务”操作都会清空
/Z的会话上下文 - 没有日志或标记文件记录“已传到第几个字节”，无法跨执行周期恢复
真正能落地的替代方案：用 rsync + WSL2 或 PowerShell + BITS
如果你必须在 Windows 上跑自动化+断点续传，绕不开两个现实路径：一是启用 WSL2 跑 rsync（支持 --partial 和 --append-verify），二是用 PowerShell 调用 BITS（Background Intelligent Transfer Service），它是 Windows 原生支持断点续传的唯一可靠服务。
使用场景：定时同步大日志、备份数据库导出文件、拉取远程 API 分卷 ZIP 包。
-
rsync -av --partial --append-verify /mnt/c/src/ user@server:/dest/—— 需提前在 WSL2 中配好 SSH 密钥和rsync - PowerShell 中用
Start-BitsTransfer，自动记录状态，崩溃后可用Get-BitsTransfer+Resume-BitsTransfer恢复 - BITS 不支持目录递归，需配合
Get-ChildItem循环提交每个文件，且目标必须是 HTTP/HTTPS 或 SMB 路径
计划任务里怎么避免“假续传”陷阱
很多人把脚本设成每5分钟运行一次，以为能“自动续上”，结果反复覆盖或跳过文件。根本问题是：计划任务本身不维护上下文，每次都是全新进程。
关键参数差异：schtasks /create /sc minute /mo 5 创建的是独立实例，不是延续前一次的线程。
- 必须手动实现“锁文件”或“状态标记”：比如每次启动先检查
transfer.lock是否存在，存在则跳过或报错 - 用
robocopy /LOG+:log.txt记录每次传输的文件名和时间，再用 PowerShell 解析日志判断哪些还没传完 - 不要依赖
robocopy /XO（跳过已存在文件）代替续传——它只比对文件名和修改时间，不校验内容，源文件被覆盖但大小没变时就会漏同步
最简可行组合：PowerShell + BITS + 计划任务
这是目前在纯 Windows 环境下唯一无需额外安装、自带权限、可跨重启恢复的方案。复杂点在于 BITS 不直接暴露“剩余字节数”，只能靠状态轮询和错误码判断是否真卡住。
示例片段（非完整脚本，仅示意关键逻辑）：
if ((Get-BitsTransfer | Where-Object {$_.JobId -eq $id}).JobState -eq "Transferred") {
Complete-BitsTransfer -BitsJob $job
} elseif ((Get-BitsTransfer | Where-Object {$_.JobId -eq $id}).JobState -eq "Error") {
Resume-BitsTransfer -BitsJob $job
}
容易踩的坑：Start-BitsTransfer 默认超时 90 分钟，大文件需显式加 -Priority High 和 -Description "backup"，否则可能被系统静默暂停；另外，计划任务触发 PowerShell 时若用“最高权限”但未勾选“不管用户是否登录都要运行”，任务会在锁屏后挂起。
BITS 的状态恢复不是秒级的，有时要等 1–2 分钟才响应 Resume-BitsTransfer，别一试不成功就换方案——多加个 Start-Sleep -Seconds 30 再查状态更稳。
