如何用 rclone chunker 把大文件自动分片上传以绕过云服务商的单文件大小限制？

云存储服务商通常对单个对象设有限制，超出该限制的大文件无法直接上传。rclone 的 chunker 叠加层（overlay remote，v1.50 引入）可以在上传时把大文件透明地切分成小块逐个发送，下载时再按顺序透明拼接还原，让你不需要自己管理分片逻辑。它可以包裹任意已配置好的 remote，也可以包裹本地路径。本文给出从配置到验证的完整操作路径。

前提：一个可用的底层 remote 和重命名能力

开始前先确认两件事（均来自 chunker 官方文档的说明）：

1. 底层 remote 必须已经配置好并验证可用。按所用后端的配置说明建好 remote 后，先用它跑一次实际读写确认没有问题，再把它作为 chunker 的底层。
2. 底层 remote 必须支持服务端 move（或 copy + delete）操作，否则 chunker 会明确拒绝启动。原因是它在操作成功后会把临时分片文件重命名为最终名称。

另外注意 remote 的写法：

• remote 的值必须包含 :，例如 myremote:path/to/dir、myremote:bucket。如果写成不带 : 的名字（如 name），rclone 会把它当成当前目录下的本地目录 name 来处理。
• remote:path 内部的一切都会被分片，外部的不会。因此使用桶型 remote（如 S3、B2、swift）时，建议把桶名写进 remote，例如 s3:bucket。

配置 chunker 叠加层 remote

通过 rclone config 交互式创建一个名为 overlay 的 remote（这个名字是文档示例用的，你可自行命名，用于和底层 remote 区分）：

rclone config

会话内容（摘自 chunker 文档 中的示例）：

No remotes found, make a new one?
n) New remote
s) Set configuration password
q) Quit config
n/s/q> n
name> overlay
Type of storage to configure.
Choose a number from below, or type in your own value
[snip]
XX / Transparently chunk/split large files
   \ "chunker"
[snip]
Storage> chunker
Remote to chunk/unchunk.
Normally should contain a ':' and a path, e.g. "myremote:path/to/dir",
"myremote:bucket" or maybe "myremote:" (not recommended).
Enter a string value. Press Enter for the default ("").
remote> remote:path
Files larger than chunk size will be split in chunks.
Enter a size with suffix K,M,G,T. Press Enter for the default ("2G").
chunk_size> 100M
Choose how chunker handles hash sums. All modes but "none" require metadata.
Enter a string value. Press Enter for the default ("md5").
Choose a number from below, or type in your own value
 1 / Pass any hash supported by wrapped remote for non-chunked files, return nothing otherwise
   \ "none"
 2 / MD5 for composite files
   \ "md5"
 3 / SHA1 for composite files
   \ "sha1"
 4 / MD5 for all files
   \ "md5all"
 5 / SHA1 for all files
   \ "sha1all"
 6 / Copying a file to chunker will request MD5 from the source falling back to SHA1 if unsupported
   \ "md5quick"
 7 / Similar to "md5quick" but prefers SHA1 over MD5
   \ "sha1quick"
hash_type> md5
Edit advanced config? (y/n)
y) Yes
n) No
y/n> n
Remote config
--------------------
[overlay]
type = chunker
remote = remote:bucket
chunk_size = 100M
hash_type = md5
--------------------
y) Yes this is OK
e) Edit this remote
d) Delete this remote
y/e/d> y

上面的示例值请替换为你自己的环境：remote:path 换成实际已配置的底层 remote 及其路径；chunk_size 设为低于你的服务商单对象限制的值，文档示例填的是 100M，K/M/G/T 后缀都支持，默认值是 2Gi；hash_type 保持 md5 即可，它决定合成文件（被分片的文件）上报哪种哈希。

hash_type 各模式的含义与文档一致：md5/sha1 只给合成文件提供对应哈希；md5all/sha1all 给所有文件都提供该哈希（底层不支持时会给每个文件都加元数据对象，小文件数量可能翻倍并产生额外费用）；md5quick/sha1quick 优先向源要主哈希、失败时退回次哈希，省 CPU 和带宽，但目的地可能出现空哈希——注意 sync 在两侧找不到兼容哈希时会退回按时间/大小比较；none 不返回哈希且要求元数据格式也不能为 none 之外的依赖项。文档建议：哈希类型最好与底层 remote 支持的类型一致，这样文件列表看起来才一致。

上传大文件

配置完成后，把大文件上传到 overlay 指向的路径即可，例如用 rclone copyto：

rclone copyto /path/to/bigfile.bin overlay:dir

其中 /path/to/bigfile.bin 替换为你要上传的本地大文件，overlay:dir 是叠加层 remote 下的目标目录。chunker 的行为由 chunker 文档 说明如下：

• 上传开始时 chunker 先检查文件大小。未超过 chunk_size 的文件直接透传给底层 remote（但见下文“小文件”的注意事项）。
• 超过 chunk_size 的文件会被透明地切成若干块，用临时名称逐块流式上传，不需要一次性落地大文件。每块为 chunk_size 字节，最后一块可能更小。
• 如果文件 size 事先未知（流式上传），chunker 会先做一份临时拷贝、记录其大小，再按上述过程分片。
• 上传完成后，临时分片文件才被重命名为最终名称。操作可以并行执行，从外部看是原子的；如果某个操作失败，隐藏的分片通常会被销毁，目标合成文件保持完整。

验证分片结果

1. 通过 overlay remote 查看合成视图。 使用 list 系命令（例如 rclone lsf）扫描目录时，chunker 会把潜在的分片文件分组、组装成原始文件名的合成目录条目，临时分片会被隐藏：

rclone lsf overlay:dir

你应该看到 bigfile.bin 这样的原始文件名条目，而不是一堆分片。

2. 直接看底层 remote 的原始布局。 绕过 overlay 直接用底层 remote 列目录，可以看到分片对象和元数据对象：

• 分片文件，默认命名格式 *.rclone_chunk.###，即 bigfile.bin.rclone_chunk.001、bigfile.bin.rclone_chunk.002 等；
• 与原始文件同名的元数据对象（默认 simplejson 格式），包含字段：ver（当前为 1）、size（合成文件总大小）、nchunks（分片数）、md5/sha1（如存在）、txn（标识当前文件版本）。

3. 校验哈希。 元数据启用 md5 时，rclone md5sum 会给出合成文件的 MD5，可与本地文件哈希比对：

rclone md5sum overlay:dir

如果元数据格式设为 none，chunker 会报告哈希为 UNSUPPORTED，此时无法用此方式校验。

4. 下载还原。 请求下载合成文件时，chunker 会按顺序拼接各分片透明还原；由于拆分是简单拼接，也可以手动把分片按序拼接得到原始内容。

缺失分片的处理：list 等命令遇到缺失或无效分片的合成文件（例如底层存储被直接改动）时，默认打印警告、跳过整组不完整分片并继续执行当前命令；设置 --chunker-fail-hard 则会在该情况下直接报错中止。

已知限制与常见处理

以下限制直接来自 chunker 文档 的 “Caveats and Limitations”，在实际使用前需要心里有数：

• 小文件场景有额外开销。目前即使文件低于分片阈值，chunker 也会在底层先创建临时文件再重命名。如果传输以小文件为主，这会产生不必要的 API 调用，并在部分后端（例如 Box）严重限制吞吐。文档给出的绕行方法：对大于阈值的文件使用 --min-size 过滤走 chunker，剩余文件再单独跑一次不带 chunker 的调用。
• 文件名长度。默认 name_format 会在文件名上加 17 个字符，操作期间还会加 7 个字符的临时后缀。很多文件系统对基础文件名限制 255 字符；用 crypt remote 作底层时限制为 143 字符。因此多数文件的最长名称是 231，chunker-over-crypt 是 119。空间紧张时可把 name_format 改为例如 *.rcc##（在每文件不超过 99 个分片时节省 10 个字符）。
• 修改分片参数不会就地重命名。在运行中的 remote 上执行 rclone config 修改分片命名格式或 chunk_size 不会重命名已存在的分片，改完后一些原来被当作分片的文件可能以普通文件出现，反之亦然。确需变更关键分片设置时，走下面的数据迁移流程。
• 中途被杀可能留下垃圾分片。长时间操作大合成文件时如果 rclone 被 kill，隐藏临时分片可能残留在目录中：list 看不到它们，但它们会占用配额。deletefile 只删除文件的活跃分片；可用底层 remote 直接查看它们。文档给出的清理办法：用 chunker remote 把该目录复制到其他位置（copy 只复制活跃分片），再对原目录 purge（会连垃圾一起删掉）。
• copy+delete 实现的 move 可能在部分服务商处被双重计费。
• 大小写不敏感的底层 remote 会被继承（例如同一目录下不能同时存在 Hello.doc 和 hello.doc）。
• 版本过旧有数据损坏风险：rclone v1.54 及以前版本有时无法识别新版 rclone 生成的元数据，文档建议保持 rclone 更新。
• transactions 设为 norename 属于实验特性（auto 同样是实验特性），文档明确提示不要在生产系统使用；norename 要求元数据格式不能是 none，且要小心不要降级 rclone 版本，旧版本会错误解析 norename 事务产生的文件。

需要更换分片参数时：数据迁移流程

如果要切换到不同的 chunk_size、hash_type、事务风格或分片命名方案，文档给出的标准做法是：

1. 把所有已分片的文件收拢到一个目录，让旧的 chunker remote 指向它。
2. 在同一个云存储上另建一个目录，按目标元数据格式、哈希类型、分片命名配置一个新的 chunker remote。
3. 运行 rclone sync：

rclone sync --interactive oldchunks: newchunks:

传输过程中数据会被透明转换，chunker 在可能时会尝试服务端 copy。这一步可能耗时较长。 4. 检查数据完整性后，删除旧 remote 的配置段。

--chunker-remote、--chunker-chunk-size、--chunker-hash-type、--chunker-name-format、--chunker-start-from、--chunker-meta-format、--chunker-fail-hard、--chunker-transactions 的完整参数说明（含环境变量名和默认值）见 chunker 文档的选项章节。