把攒了几年的片库往新盘上搬，是我最不想干又不得不干的一件事。资源管理器拖过去，进度条先是很乐观地写「剩余 40 分钟」，十分钟后变成「剩余 6 小时」，中间还弹一次「文件正在使用」。后来我干脆把命令行翻出来重跑，同一块盘、同一批文件，时间差了一倍多，差的其实只有一个参数：一次拷几个。
这篇不讲理论，只讲我在这台机器上量出来的数字，以及最后留在批处理里的那行命令。
先说测试条件，免得数字对不上：Ryzen 5 3550H（4 核 8 线程）、16GB 内存、单块 512GB 的 SATA SSD，Windows 11 25H2。所有复制都是同一块盘上从目录 A 到目录 B，源和目标在同一个分区。也就是说，下面的绝对速度比外置硬盘、机械盘都好看得多，能看的是相对差距——换成机械盘，差距只会更大，不会更小。
小文件慢，不是盘慢，是「一次一个」慢
我造了两组数据。第一组是 20000 个 16KB 的小文件，总共 312MB，模拟的是字幕、海报、nfo、分集缩略图这类东西。第二组是 4000 个 256KB 的文件，1GB 左右。第三组是一个 2GB 的随机内容单文件。
先看第一组，同一批文件、同一条命令，只改 /MT：
| 命令 | 第一轮 | 第二轮 |
| --- | --- | --- |
| robocopy /MT:1 | 45.2 秒（443 个/秒） | 39.4 秒（507 个/秒） |
| robocopy /MT:8 | 12.9 秒（1551 个/秒） | 14.9 秒（1345 个/秒） |
| robocopy /MT:32 | 11.9 秒（1674 个/秒） | 10.0 秒（2006 个/秒） |
| rclone --transfers 16 | 24.5 秒（816 个/秒） | — |
| rclone --transfers 32 | 22.5 秒（889 个/秒） | — |
单线程 45 秒，8 线程 13 秒，差了 3.5 倍。而吞吐呢？312MB 除以 45 秒，只有 7MB/s。这块 SSD 顺序读能跑 500MB/s 以上，也就是说单线程拷小文件时，盘有 98% 的时间在闲着——时间全花在「打开、建目录项、写元数据、关闭」这一套动作的往返上，一次只能等一个文件。
这也是为什么「片库搬得慢」的抱怨经常是错怪了硬盘。一个 4TB 的片库，如果是 2000 个 2GB 的 mkv，那基本是顺序读写，很快就完；如果里面塞了十几万张小图、几百集带字幕的分集文件，那才叫慢。
/MT:32 比 /MT:8 还能再快一点，但不是线性的：13 秒到 10 秒，多榨 20% 左右。线程数不是越多越好，微软自己的文档写的是 1~128，我试到 32 就没再往上加，因为收益已经很薄，反而更容易把机械盘的磁头晃成筛子。经验值：SSD 上 16~32，机械盘 8 封顶。
中间那组 4000 个 256KB 的文件，数字就很不听话：/MT:1 跑了 11~15 秒，/MT:8 在 2.4 秒到 8.1 秒之间跳，/MT:32 在 2.4 秒到 11.2 秒之间跳。同一个命令跑三次能差三倍。原因我猜是实时防护在扫新建的 .bin，加上这一档文件大小已经能喂饱盘了，瓶颈从「元数据」转到了「盘」，线程数再多也只是排队。所以别指望背参数，先拿你自己的数据跑一遍更实在。
大文件是另一回事：/J、xcopy、rclone 三种走法
2GB 单文件，同一块盘，四轮取稳定值：
| 命令 | 耗时 | 折算吞吐 |
| --- | --- | --- |
| robocopy /MT:8 | 2.13 秒 / 2.03 秒 | 约 960MB/s |
| robocopy /J（无缓冲 I/O） | 3.38 秒 | 约 606MB/s |
| xcopy /Y /Q | 6.04 秒 | 约 339MB/s |
| rclone copy（默认） | 8.14 秒 / 8.05 秒 | 约 254MB/s |
| rclone --multi-thread-streams 8 | 10.65 秒 | 约 192MB/s |
| rclone --multi-thread-streams 16 | 11.93 秒 | 约 172MB/s |
xcopy 是很多人还在用的老工具，它的默认缓冲区是 64KB 一档，传大文件时系统调用次数太多，只有 robocopy 的 35%。robocopy /J 走的是无缓冲 I/O，理论上是给超大文件准备的，但在数据已经在系统缓存里的情况下反而比默认慢——因为它绕过了缓存，每次都要真去问盘。这个参数的意义在「拷一个比内存还大的文件」，如果一次只搬几个 G，默认就好。
真正值得记的是最后两行。
rclone 的多线程流，在本地盘上是负优化
--multi-thread-streams 是 rclone 的招牌参数，把一个大文件切成 N 段并发读写，云盘上确实能把单连接的限速打满。但我在这块本地 SSD 上试的时候，8 段比默认慢 30%，16 段慢 48%。
同一个物理盘上，读和写本来就是互相抢的，切成 16 段之后磁头/闪存队列要在 16 个位置来回跳，顺序性被打散，收益全被抵消。我还试了 --local-no-sparse（用来排除「全零区域被写成稀疏文件」造成的假快）和 --buffer-size 64M，分别是 7.96 秒和 7.81 秒，和默认基本一样——说明 rclone 慢的原因不在缓冲，而在它自己的文件读写路径本身就比 robocopy 重。
所以结论很清楚：本地搬数据用 robocopy，rclone 留给网盘和远端。它的多线程流参数不要照搬到本地路径上，那是给别人准备的。
搬完要不要校验：2GB 测四种哈希
这是我最纠结的一步。4TB 搬完逐个校验，听起来像要熬一个通宵，很多人就是怕这个才跳过。我拿 2GB 文件量了一下（两轮，文件已进缓存，纯算法吞吐）：
| 方式 | 第一轮 | 第二轮 | 折算吞吐 |
| --- | --- | --- | --- |
| certutil -hashfile MD5 | 8.66 秒 | 8.74 秒 | 约 236MB/s |
| certutil -hashfile SHA1 | 8.37 秒 | 8.35 秒 | 约 244MB/s |
| certutil -hashfile SHA256 | 4.09 秒 | 3.98 秒 | 约 510MB/s |
| rclone hashsum md5 | 6.29 秒 | 6.24 秒 | 约 325MB/s |
| rclone hashsum sha256 | 3.68 秒 | 3.72 秒 | 约 550MB/s |
| rclone hashsum blake3 | 3.53 秒 | 3.50 秒 | 约 580MB/s |
有点反直觉：SHA256 比 MD5 快一倍。这不是测量错误，两轮数字都很稳。原因大概是这颗 AMD 的 SHA 扩展指令被 SHA256 用上了，而 MD5 的实现还是纯软件跑循环。所以你如果还按「MD5 快、SHA256 慢」的老观念选算法，在近几年的 CPU 上正好选反了。
换算一下才有感觉：按 550MB/s 算，4TB 校验一遍约 2 小时；用 MD5 按 325MB/s 算，约 3.4 小时。听起来很久，但这只是 CPU 和内存的速度——真去读一块 150MB/s 的外置机械盘，4TB 光读就要 7 个多小时，校验根本不会额外增加多少时间，因为盘才是瓶颈。
一句话：校验不要省，慢的不是算法。想再快就用 blake3 或者 xxh3，别在 MD5 上省。
顺便提醒，robocopy 自己是不做内容校验的，它默认只比文件大小和修改时间。也就是说 /MIR 跑完显示「成功」，只代表「大小和时间对上了」，不代表文件内容没坏。要校验就单独跑一遍 hashsum，把结果存成清单，半年后再对一次。
我最后留在批处理里的那行命令
robocopy "D:\影片" "E:\影片" /E /MT:16 /R:1 /W:1 /NP /NFL /NDL /TEE /LOG:copy.log几个参数值得说清楚：
/R:1 /W:1：默认是重试 100 万次、每次等 30 秒。碰上「文件正在使用」，一条命令能卡到天亮。改成重试 1 次、等 1 秒，失败的记进日志，回头单独处理。/NFL /NDL：不刷文件名和目录名。二十万个文件刷屏会让控制台本身变成瓶颈，我第一次跑就吃了这个亏，加不加这两个参数，整体能差 10% 左右。/NP：不刷百分比进度，同理。/TEE加/LOG：屏幕和文件都留一份，事后能对着日志找漏掉的文件。- 别顺手用
/MIR：它是「镜像」，会删掉目标盘里源盘没有的东西。搬片库时源盘少一个目录，目标盘上就跟着少一片，删完没处找。
还有个老坑：路径结尾的反斜杠。写成 "D:\影片\"，末尾那个反斜杠会把引号转义掉，robocopy 会收到一个残缺的参数，然后开始报「无效参数 #3」。要么去掉结尾反斜杠，要么写成 "D:\影片\\"。
判定成功也别用 if errorlevel 1。robocopy 的退出码 0~7 全是成功（1 表示有文件被复制、2 表示有额外文件、3 表示两者都有），8 以上才是真失败。批处理里写 if %ERRORLEVEL% GEQ 8 才对。
最后一条经验：搬完先别急着删源盘。找个能播的片子从头拖到尾，再抽查几个字幕文件，确认没有 0 字节的残缺文件——我这批里就有一个 4.7GB 的 mkv 在拷贝中因为休眠断过一次，大小对得上，实际尾部是空的，只有播到 90 分钟才看得出来。
你们搬盘的时候是直接拖，还是也写了条命令？有没有遇到过拷完「大小对、内容坏」的情况？