搞云存储的人迟早都会碰到 Azure Blob Storage。不管是给应用存日志、给前端放静态图片，还是给大数据任务当中间存储，这个对象存储服务基本是绕不开的一站。这篇文章不会带你翻完整本官方文档，我直接把平时用得最多的那套基本用法捋一遍，包括账号体系、认证方式、上传下载的实践写法，还有几个我实际踩过、查了挺久才搞明白的坑。

适合谁看？刚上手 Azure 的人、要把本地文件系统搬到对象存储的团队、还有写脚本做自动化备份的运维同学。看完你能直接照着写一个能用的上传下载 Demo，也明白为什么有些看起来没问题的写法，到生产环境就崩了。

1. 先搞懂 Blob 是干什么的，再动代码

1.1 Blob 在整个 Azure Storage 里的定位

Azure Storage 本身是一个大的云存储服务，下面按数据形态分成几类：Blob 存非结构化数据，也就是文件本身；Table 存键值型数据；Queue 提供消息队列；Files 提供托管文件共享。Blob 这个名字实际上是 Binary Large Object 的缩写，早期就是给那种大二进制对象用的，现在发展成通用对象存储。你的图片、日志、安装包、备份文件、训练数据集，只要是非结构化数据，基本都往 Blob 里放。

很多团队用 Blob 的第一驱动力是替代本地文件服务器。本地磁盘最大的问题是容量上限、备份成本和单点故障，对象存储把这些都外包了，按量付费，持久性指标也远比自建存储可靠。另一个常见场景是把 Blob 当数据湖底座，计算框架直接读里面的大文件做分析。它解决的本质上就是"海量非结构化数据怎么低成本、高可靠地存下来，并且能随时随地通过 API 访问"这个问题。

1.2 三种 Blob 类型，按需选而不是乱选

Blob 底下还分成 Block Blob、Append Blob、Page Blob 三种。写代码前先把这个分清楚，不然到后面迁移很痛苦。

Block Blob 最常用，它把文件拆成一个个块（Block）上传，每个块独立校验，最后提交块列表合并成一个文件。优点是单文件体积上限大，支持断点续传，适合存图片、视频、压缩包、日志文件这些普遍场景。

Append Blob 是专门为追加操作设计的，只允许在末尾追加块，不允许覆盖或随机写。典型用途是日志流，比如把多个实例的日志持续写进同一个 Blob。它天然保证并发追加的原子性，不用自己加锁。

Page Blob 是"磁盘风格"的存储，随机读写，按 512 字节页组织。它主要服务虚拟机磁盘这类场景，普通应用开发基本碰不到。

我见过不少新人用错了：拿 Append Blob 去持续修改文件内容，或者为了写日志硬上 Block Blob 每次全量上传，性能都很糟糕。选型真没那么复杂：普通文件选 Block，日志追加选 Append，虚拟磁盘类才选 Page。

1.3 访问层级：低成本方案的入口

访问层级就是热、冷、归档三档。热访问层费用高但访问即时；冷访问层存储成本低，数据访问时有少量延迟和取档费用，适合几个月不动的存量数据；归档层最便宜，但取回时间以小时计，只适合半年以上不访问的备份。

层级可以设置在存储账号级，也可以在单个 Blob 上单独指定。实际项目里最省钱的玩法是默认热访问保证体验，配合生命周期策略把老数据自动降级到冷或归档。这块后面单独展开讲，先记住这个组合思路就行。

2. 开始操作前必须理解的结构与认证

2.1 存储账号、容器、Blob 三层关系

Blob 的数据路径是固定的三层：存储账号在顶层，类似命名空间，所有的计费、层级策略、网络规则都挂在这个层级；账号下面建容器，容器相当于文件夹的隔离域，但注意它并不真正嵌套，没有真实的文件夹层级；真正存数据的是 Blob，名字里可以用斜杠模仿目录结构，比如logs/2025/06/01/app.log，这纯粹是命名约定，内部还是一个扁平列表。

这个设计有个直接后果：你没法像操作本地文件系统那样"进入目录"。查询时要提供前缀匹配，比如列所有logs/2025/开头的 Blob。分页、前缀筛选这些都是在代码里处理的逻辑。理解了这一点，后面写列 Blob 的逻辑会顺手很多。

2.2 认证方式：从连接字符串到托管身份

访问 Blob 有几种主流认证方式，我按使用频次从高到低说。

账号密钥最简单，就是存储账号的两个主备 Key，拿到 Key 意味着对这个账号下所有数据有完全控制权。连接字符串就是把账号名、密钥和 Endpoint 拼在一起，本地开发、写脚本、构建一次性迁移工具时最常用。

共享访问签名（SAS）是在密钥基础上生成的受限凭证，可以限定容器、Blob、权限（读、写、删除、列表等）和有效期，适合把资源临时授权给第三方。比如生成一个只读的 URL，让没有云账号的人也能下载某个文件。

托管身份（Managed Identity）是生产环境的推荐做法，让应用在云上通过身份获得 Blob 访问权限，完全不用在代码里管理密钥。账号 Key 和 SAS 都存在泄漏和轮换的问题，托管身份机制能把这些运维负担直接省掉。

最后还有一种方式是用 IDaaS 身份做 RBAC 角色授权，适合企业内部强制合规审计的场景。对大多数入门项目来说，先把连接字符串和 SAS 用熟，生产环境再去拥抱托管身份，这个路径比较平滑。

2.3 我的选型建议

本地开发用连接字符串配账号 Key，最简单直接；给别人的临时下载链接用 SAS；应用部署到云上无缝切换到托管身份，代码层面改一行认证初始化就行。不要把账号 Key 硬编码到前端页面或公开仓库里，这种事故一旦发生，影响面是整个存储账号，不是一个容器也不是一个文件。

3. 核心操作的代码实现：上传、下载、列出、删除

3.1 环境准备与客户端初始化

我用 Python SDKazure-storage-blobv12 举例，它是目前官方主推的版本。安装一行命令：

pip install azure-storage-blob

初始化客户端的标准写法：

from azure.storage.blob import BlobServiceClient conn_str = ( "DefaultEndpointsProtocol=https;" "AccountName=你的存储账号名;" "AccountKey=你的账号密钥;" "EndpointSuffix=core.windows.net" ) # BlobServiceClient 是顶层入口 blob_service = BlobServiceClient.from_connection_string(conn_str) # 拿到容器客户端 container_client = blob_service.get_container_client("mycontainer") # 再拿到 Blob 客户端 blob_client = container_client.get_blob_client("docs/readme.txt")

注意连接字符串的格式一个分号都不能错。实际操作里我建议优先用os.environ读取环境变量，而不是把 Key 直接写在源码里，这样测试、分支合并时不会把密钥带进代码库。

3.2 上传：几种姿势各有使用场景

第一种最无脑，适合小文件：

with open("readme.txt", "rb") as f: blob_client.upload_blob(f, overwrite=True)

第二种是流式上传，适合从网络流或管道写入，传一个可迭代对象就行，可以避免把整个文件加载进内存。第三种是分块上传，我在这里展开讲一下，因为大文件必须走这个思路。

Block Blob 的上限能力很强，但超过一定大小必须分块。分块上传的手动写法是 stage_block 加 commit_block_list：

from azure.storage.blob import BlobBlock blob_client = container_client.get_blob_client("bigdata/2025-model.tar.gz") chunk_size = 8 * 1024 * 1024 # 8MB一块 block_ids = [] block_num = 1 with open("model.tar.gz", "rb") as f: while True: chunk = f.read(chunk_size) if not chunk: break block_id = f"block-{block_num:06d}" blob_client.stage_block(block_id=block_id, data=chunk) block_ids.append(BlobBlock(block_id=block_id)) block_num += 1 blob_client.commit_block_list(block_ids, overwrite=True)

为什么块大小选 8MB？这是实践中比较稳妥的平衡点：块太小 HTTP 请求数量爆炸，块太大单次上传失败重试成本高。SDK 官方的默认策略也大致在这个量级。生产代码里还应该加指数退避重试，我习惯把每块的重试次数放到 3 到 5 次，设置合理超时而不是无限等待。

overwrite=True这个参数特别容易被忽略。默认情况下如果同名 Blob 已存在，上传会报错，服务端返回 409。想覆盖先想清楚是不是真要覆盖，尤其日志场景更应该用时间戳或随机 ID 命名。误开全局覆盖导致历史数据被冲掉的情况，我在项目里见过不止一次。

3.3 下载与流式读取

下载 Blob 最常用的写法：

download = blob_client.download_blob() with open("download.txt", "wb") as f: f.write(download.readall())

文件小这么写没问题。大文件要小心readall()会把整个内容一次性读入内存。官方 SDK 同时支持readinto分块写文件，我实际用的方式是直接返回流式迭代：

download = blob_client.download_blob() with open("download.bin", "wb") as f: for chunk in download.chunks(): f.write(chunk)

后台的实现是每次拉取一个可配置的块范围，避免内存峰值。做文件断点续传下载时，可以先拿download.size判断总大小，再通过offset参数续传剩余部分。

3.4 列出 Blob：前缀、分页与性能

列出一个容器下所有 Blob：

blob_list = container_client.list_blobs(name_starts_with="logs/") for blob in blob_list: print(blob.name, blob.size, blob.last_modified)

这个接口返回的是迭代器，SDK 内部自动处理分页，所以通常不需要手写分页循环。但如果数据量特别大，建议自己控制results_per_page配合by_page手动翻页，尤其是要边遍历边删除的场景，避免内存里累积太多对象。

按前缀筛选很实用。文件名如果设计成logs/2025/06/01/xxx.log，用name_starts_with="logs/2025/06/01/"就能精确拉出某一天的日志。所以对象存储的命名设计就是你的索引策略，前缀规划得好，查询就是一次接口调用的事。

3.5 删除操作与软删除保护

删除 Blob：

blob_client.delete_blob()

删除容器：

container_client.delete_container()

这里有个特别容易忽视的功能：Blob 的软删除。开启后，删除不是真正抹掉，而是保留一段可恢复期，默认是 7 天，可以调。我做自动化清理脚本时一开始没开软删除，误删了一批测试数据，恢复花了半天。从那以后凡是生产账号，我先确认软删除打开再谈删除逻辑。真删和软删在 SDK 参数上也有区别，但要恢复只能走版本历史或快照。所以这也是为什么对关键数据，上传时顺带创建快照很有价值。

4. 进阶玩法：权限、生命周期与性能

4.1 容器权限与匿名访问

容器有几种访问级别：私有（默认）、Blob 级别匿名读、容器级别匿名读。私有意味着所有访问都要认证；Blob 级别匿名读允许不知道密钥的人直接通过 URL 读容器内所有 Blob；容器级别匿名读还额外允许列出 Blob。

静态网站托管场景经常用到匿名读。有些项目把前端静态资源直接部署到 Blob，配一个开放读权限的容器，然后通过 CDN 加速。这里要特别提醒：容器一旦开了匿名读，里面任何一个 Blob 都暴露了，不能拿它当"对外开放指定文件"的方案。想精确开放单个文件，正确做法是生成 SAS 链接。

4.2 SAS 令牌：临时授权的正确姿势

SAS 生成其实很简单：

from datetime import datetime, timedelta, timezone from azure.storage.blob import generate_blob_sas, BlobSasPermissions sas_token = generate_blob_sas( account_name="你的存储账号名", account_key="你的账号密钥", container_name="mycontainer", blob_name="docs/report.pdf", permission=BlobSasPermissions(read=True), expiry=datetime.now(timezone.utc) + timedelta(days=7), ) blob_url = ( f"https://你的存储账号名.blob.core.windows.net/" f"mycontainer/docs/report.pdf?{sas_token}" )

我的权限控制习惯是：权限尽量按最小化原则给，只给读不给写；有效期不要太长，文件分享一般设几天足矣；把 SAS 生成封装成一个函数，统一设置默认过期时间，方便审计。另外 SAS 分账号级和服务级两种，上面这个属于服务级，只针对具体 Blob，信息泄露的爆炸半径要小得多。

4.3 生命周期管理：自动降温和清理

生命周期管理规则解决的是"数据不清理会持续烧钱"的问题。它通过 JSON 策略声明，也可以直接在控制台可视化配置。一个典型规则：

• 创建后 30 天，把 Blob 从热访问层移到冷访问层
• 创建后 90 天，移到归档层
• 创建后 365 天，删除 Blob

有了这个，日志存储、备份这类数据就不用运维人肉手动清理了。配置后系统需要时间扫描，不会立刻生效，我看到有人在社区抱怨"都设置半天了还没动"，其实调度周期不是一个即时过程，要有点耐心。另外，生命周期规则只作用于规则匹配的 Blob，如果账号下面某个容器不想被清理，记得用前缀或筛选条件把它排除掉。

4.4 性能与并发优化心得

并发上传几十个对象时，BlobServiceClient是线程安全的，可以多个线程共享一个客户端。我建议把并发数控制在 10 到 20 之间，先测一下实际吞吐，不是线程越多越快，太多反而触发服务端限流，出现 429 错误。

小文件场景真正的瓶颈多半在网络延迟上。我处理大量小文件时，先全部压成分卷压缩包再上传，或用 AzCopy 这类专门工具做批量同步。开发阶段如果频繁上传下载几 KB 的图片，本地连接服务端往返开销远大于传输本身，这时候节省接口调用比优化单个请求更有价值。

5. 踩坑实录：我亲自排过的问题

5.1 连接字符串拼接后一直认证失败

常见原因是密钥里混入了换行符或空格。从控制台复制 Key 时，复制到多余的空格几乎看不出来，字符串两端 strip 处理一下就好。另一个低级但高频的错误是存储账号名少写了一个字符，导致访问时解析出来的 Endpoint 完全不对，客户端不报错，请求发出去服务端返回 404 或 403。排查这类问题，第一件事就是打印连接字符串里的账号名和 Endpoint 确认拼写。

5.2 上传大文件超时

一开始我没设置客户端超时，默认超时对几十 MB 的文件就显露出问题了。解决方案：分块上传，每块重试 3 到 5 次，并设置合理的超时时间。另外确认一下网络环境，比如有些办公网络对长连接有代理截断，这种外部因素很难靠调参数解决，建议先测一下到 Blob 服务端的真实连通性。

5.3 列 Blob 数量看起来不对

列出来永远只有 5000 条就停了？SDK 默认会分页拉取全部，但如果你用了by_page手动翻页却忘了继续取下一页，当然只拿到第一页。还有种情况是数据一致性问题，刚上传完立刻列，偶发看不到，因为列表索引还有短暂延迟。对即时性要求高的场景，直接访问具体 Blob 而不是依赖 list 结果。

5.4 生命周期规则不生效

我上面提过调度延迟，但规则不生效还有一个常见原因：把规则配置在账号层但过滤条件限制了容器前缀，拼写不一致导致没有任何对象匹配。写规则时先在文档里模拟跑一遍对象名，确保前缀能命中。想确认到底有没有生效，去监控指标看某容器下 Blob 的访问层分布变化，比盯着控制台干看靠谱。

5.5 常见问题速查表

我在实际项目里用 Blob 存过从几 KB 的验证码图片到几十 GB 的模型备份，感受就一句话：对象存储的基本用法不难，难的是从一开始就把命名、认证和运维策略设计对。我的习惯是新建存储账号先开软删除，再配置好生命周期默认规则，然后才让团队往里写数据。这几个动作成本极低，但能挡住绝大多数将来会让人熬夜的故障。你上手的时候，也建议花十分钟先把这几件事做了，后面会轻松非常多。