如何用DotNet Core Web API重命名Azure Blob Container内的文件且无需重新上传

首先明确核心逻辑：Azure 普通Blob容器原生没有提供原地重命名接口，我们可以通过存储端服务内复制+源Blob删除的方式实现等效重命名，整个过程的文件字节流完全在Azure存储内网流转，不会经过Web API服务器，自然不需要额外的文件重新上传操作。

前置准备 #

• 项目引入官方最新的Azure.Storage.Blobs NuGet包，弃用旧版WindowsAzure.Storage依赖
• 为应用绑定的存储账号身份配置对应权限：源Blob的读权限、目标Blob的写创建权限、源Blob的删除权限

核心实现逻辑 #

• 为什么这个方案不需要重新上传？：Azure的Copy Blob操作由存储后端直接拉取源Blob内容生成目标文件，同存储账号下的复制全程走内网，既不会占用Web API服务器的公网带宽，也不需要把Blob内容拉到应用进程里处理，完全符合不重新上传的要求。
• 标准执行流程：
  1. 通过DI注入的BlobServiceClient获取对应容器、源Blob、目标新Blob的客户端实例
  2. 对目标Blob客户端调用StartCopyFromUriAsync，传入源Blob的URI，启动存储端异步复制
  3. 轮询校验Blob属性，确认复制状态为成功后，再执行源Blob的删除操作
  4. 复制过程中一旦出现失败、中止的状态，直接抛出错误，绝对不删除源文件，避免数据丢失

特殊场景优化 #

• 如果你的存储账号开启了ADLS Gen2层级命名空间（也就是容器支持文件系统式的路径结构），可以直接对DataLakePathClient调用原生的RenameAsync方法，这是存储端的原子操作，比复制+删除的方案性能更高，也没有额外的步骤

示例API端点代码 #

// 在Program.cs中提前注册BlobServiceClient到DI容器
builder.Services.AddAzureClients(clientBuilder =>
{
    clientBuilder.AddBlobServiceClient(builder.Configuration["AzureStorage:ConnectionString"]);
});

// 控制器中注入使用
public class BlobOperationController : ControllerBase
{
    private readonly BlobServiceClient _blobServiceClient;
    public BlobOperationController(BlobServiceClient blobServiceClient)
    {
        _blobServiceClient = blobServiceClient;
    }

    [HttpPost("api/blob/rename")]
    public async Task<IActionResult> RenameBlob(
        [FromQuery] string containerName,
        [FromQuery] string sourceBlobPath,
        [FromQuery] string newBlobPath,
        CancellationToken ct)
    {
        var containerClient = _blobServiceClient.GetBlobContainerClient(containerName);
        var sourceBlobClient = containerClient.GetBlobClient(sourceBlobPath);
        var targetBlobClient = containerClient.GetBlobClient(newBlobPath);

        // 启动存储端内部复制，全程不经过应用服务器
        await targetBlobClient.StartCopyFromUriAsync(sourceBlobClient.Uri, cancellationToken: ct);

        // 循环校验复制状态，直到完成或失败
        while (true)
        {
            var targetProps = await targetBlobClient.GetPropertiesAsync(cancellationToken: ct);
            var copyStatus = targetProps.Value.CopyStatus;
            
            if (copyStatus == CopyStatus.Success)
                break;
            
            if (copyStatus == CopyStatus.Failed || copyStatus == CopyStatus.Aborted)
                return BadRequest("Blob复制失败，原文件未做任何修改");

            await Task.Delay(500, ct);
        }

        // 复制成功后删除源文件，完成等效重命名
        await sourceBlobClient.DeleteAsync(cancellationToken: ct);
        return Ok("文件重命名完成");
    }
}

常见避坑点 #

• 不要颠倒执行顺序：绝对不能先删除源Blob再启动复制，一旦复制失败会直接造成文件永久丢失
• 大文件复制要留出足够的轮询间隔，单块Blob最大支持4.7TB，复制是异步过程，不要刚启动就立刻判断完成
• 如果源Blob开启了不可变策略、版本控制，要在删除源Blob前确认不会违反合规策略，必要时把源Blob转成版本保留状态，而不是直接硬删除
• 不要在应用端实现“下载源Blob流-上传新Blob流”的复制逻辑，这个会完整占用你的Web服务器带宽和内存，完全违背不重新上传的要求

内容的提问来源于stack exchange，提问作者Chindara