用 gcloud 批量迁移 Cloud Storage 桶时，我卡在权限继承上

上周帮一个做跨境物流的客户把数据从旧项目迁到新项目，两个项目都在同一个组织下，但分属不同的文件夹。旧项目里有 47 个 Cloud Storage 桶，总大小约 2.3 TB，桶命名的前缀不统一，有些带 prod-，有些带 legacy-，还有几个是纯业务名。客户希望迁移后桶名保持原样，只换归属项目。

我一开始想用 gcloud storage cp --recursive 逐桶拷贝，后来发现这样会丢失桶级 IAM 策略和对象生命周期规则。于是改成两步：先在新项目建同名桶，再用 gcloud storage rsync 同步对象，最后单独回填策略。建桶命令我用了一个脚本循环：

for b in $(gcloud storage ls --project=old-proj | sed 's|gs://||; s|/||'); do
  gcloud storage buckets create gs://$b --project=new-proj --location=asia-east1 --default-storage-class=STANDARD
done

对象同步用 rsync 加 --delete-unmatched-destination-objects 保证一致性，耗时约 4 小时。但真正卡住的是 IAM：旧桶上绑了 3 个自定义角色，新项目里没有这些角色，直接 get-iam-policy 再 set-iam-policy 会报错。我最后是先在新项目手动创建同名自定义角色，再回填策略。

这个流程的代价是迁移期间旧桶不能写入，否则会漏对象。我们挑了凌晨 1 点到 5 点的窗口，但 rsync 不会自动处理并发写入，所以我加了 --dry-run 先跑一遍对比文件数。边界条件是：如果桶里有版本控制开启的对象，rsync 默认只同步当前版本，历史版本会静默丢失。我踩过的坑是有一个桶开了对象版本控制，迁移后客户问旧版本怎么没了，我只能从旧桶补拉。

你们在跨项目迁桶时，是继续用 rsync 还是直接上 Storage Transfer Service？后者的代理模式对自定义角色支持怎么样？