第一次接触 Azure Blob Storage 的时候我其实挺不屑的一个对象存储服务官方文档翻来覆去就是“创建账户、创建容器、上传文件、下载文件”这四板斧感觉比操作本地文件夹还简单能有什么坑直到后来在某个在线教育项目里要把几十万份课程视频、课件PDF和学员头像全部迁到 Blob 上才发现所谓“基本用法”背后还藏着一堆文档没写透的东西——连接字符串放哪最容易泄露、容器访问级别设错了会裸奔、SAS 令牌过期时间算不对导致生产故障、并发上传同一路径会发生什么这些都是实际跑起来才撞上的问题。这篇文章就围绕 Azure Blob Storage 的日常使用场景把从建账户到写代码上传下载、再到权限取舍的完整链路捋一遍。内容偏实战适合刚接手 Azure 项目、想快速把 Blob 用起来的开发者也适合那些已经用了一阵子但总感觉某些行为“怪怪的”的朋友。放心我不会粘贴大段官方文档只讲我试过、踩过、验证过的东西。1. 先从一张“档案柜”图看懂 Blob 的三层结构Azure Blob Storage 的宣传语总爱讲“无限扩展、高可用、对象存储”听起来很玄。但说白了它的数据组织方式和线下实体档案柜几乎没有区别档案室里有多个柜子每个柜子里有多个文件夹文件夹里装着一份份文件。对应到 Blob 上就是“存储账户 / 容器 / Blob”这三层。存储账户Storage Account是顶层单位相当于整个档案室。你在里面设置地域、冗余策略、访问层这些全局属性所有 Blob 数据都住在这个账户下。一个账户可以开很多个容器Container容器相当于档案柜主要作用是给 Blob 划定命名空间和权限边界。最底层的 Blob 才是真正存储的数据对象它本身就是一个二进制文件可以是一个 JPEG 图片、一个 MP4 视频、一段日志文本甚至是一个数据库备份文件Azure 不关心内容是什么只当它是字节流。这里有个初学者最容易忽略的细节Blob 的“目录”其实是不存在的。你看到container/videos/2024/01/course.mp4这种路径看起来有层级实际只是 Blob 的名称里包含了斜杠字符而已。容器里面是一个扁平的命名空间所有 Blob 名称都是平铺存储的。“虚拟目录”这个概念是 SDK 和 Azure Portal 为了人眼友好做出来的假象。这意味着你在代码里没法直接“进入某个目录”要么列出所有名称带指定前缀的 Blob要么直接按完整名称定位。Blob 本身又分三种类型Block Blob块 Blob、Append Blob追加 Blob、Page Blob页 Blob。日常 95% 的场景用块 Blob 就对了它适合存储静态文件和媒体文件上传时把大文件拆成小块分别传输失败后只需要重传失败的小块追加 Blob 适合写日志这类“只往后加”的数据流页 Blob 是给虚拟硬盘文件用的优化了随机读写能力。做文件存储的朋友直接用块 Blob别多看另外两个等真需要了再学也不迟。存储账户Storage Account └── 容器Container——相当于逻辑分组 └── Blob——例如 videos/2024/01/course.mp4 实际名称Name: videos/2024/01/course.mp4 元数据Metadata: 键值对例如 标题课程介绍 属性Properties: ContentType、ContentLength 等我第一次建容器的时候很迷惑容器名称居然要求小写字母、数字和连字符而且不能以连字符开头。这跟 Blob 名称的命名规则不一样Blob 名称几乎可以放任何字符包括中文和空格只要你做好 URL 编码。建议项目里统一用英文小写 连字符给容器起名Blob 名称则保持原有文件名查询方便也避免了一堆转义问题。三层结构整明白了接下来就是怎么把这个档案柜搬进代码里。2. 创建存储账户和容器时别急着点“创建”先想清楚冗余和访问层很多时候我们用 Azure 是直接抄文档写的命令账户能建出来、代码能跑通就觉得完事了。但存储账户的创建环节有两项配置会在后续几个月里持续影响你的账单和可用性创建后虽然部分可改改起来却伤筋动骨。第一个是冗余策略。默认的 LRS本地冗余存储会把数据复制到同一个数据中心内的三个副本成本最低但整个数据中心挂了数据也就没了。如果在做生产项目、尤其是数据不能丢的业务建议至少用 ZRS区域冗余存储它会把副本分布到同一个区域内的三个可用区可用性比 LRS 高一个量级。至于 GRS 和 GZRS会把数据复制到配对区域适合做跨地域灾难恢复但读取故障区域的副本是只读的别指望当双活。我的习惯是生产环境选 ZRS开发测试环境用 LRS省下的钱拿去买奶茶不香吗冗余策略创建之后不能直接更改只能迁移所以想清楚再下手。第二个是访问层Access Tier。每个存储账户都有默认访问层热Hot或冷Cool。热访问层适合频繁读写的数据存储单价高但访问单价低冷访问层存储单价便宜但每次读写都要额外付访问费。这条对应到 Blob 层面还有更细粒度单个 Blob 也能单独设置访问层热/冷/归档。归档层最便宜但把归档文件重新变为可读状态需要等待数小时到几十小时。放到真实场景里有个朋友做过一个图片托管系统客户上传的图片未来 30 天会被频繁访问之后访问量骤降。他没做任何分层策略全部数据躺在热层月末账单出来直接傻眼。正确做法是用生命周期管理策略比如“创建后 30 天转为冷层90 天后转为归档层”这在 Azure Portal 的“生命周期管理”里配置一条规则就能搞定不需要写代码。{ rules: [ { name: coolAfter30Days, enabled: true, type: Lifecycle, definition: { actions: { baseBlob: { tierToCool: { daysAfterModificationGreaterThan: 30 }, tierToArchive: { daysAfterModificationGreaterThan: 90 } } }, filters: { blobTypes: [ blockBlob ], prefixMatch: [ images/ ] } } } ] }不过这个配置有几个容易忽略的坑生命周期规则不会对 30 天内有过访问修改的 Blob 生效这里判定的不是“读取次数”而是最后修改时间另外规则不是实时的Azure 一般每天跑一次所以账单变化会迟几天。设成归档层之后如果用户想要下载这个文件得先操作“解除冻结”这个等待时间必须提前告诉业务方不然线上就会出现文件点不动、用户疯狂提工单的尴尬场景。容器本身创建就简单了Azure CLI 一条命令的事但别忘了同时设置容器访问级别az storage container create \ --name course-files \ --account-name myteststorage \ --account-key your-key \ --public-access off这段命令里我故意把--public-access写成 off这是最安全的选择。很多教程为了演示方便会写container或blob让容器内所有 Blob 都能匿名访问。我的建议是默认永远选 off永不公开。确实需要对外分享文件时用 SAS 令牌去控制有效期和权限后面章节会细讲为什么。3. 代码实操用 Python SDK 走一遍上传、下载、列出和删除账户建好了容器有了接下来就是写代码。Azure 官方提供了很多语言的 SDKJava、Python、Node、Go 都有。我平时 Python 用得多下面的例子基于azure-storage-blob这个包版本用 12.x 起步老版 2.x 已经废弃网上搜到的旧教程会让你踩坑认准新版 SDK 的 API 风格。3.1 安装和连接到存储账户pip install azure-storage-blob连接方式有两种主流姿势。一种是直接拿连接字符串Connection String在 Azure Portal 的“访问密钥”里能看到格式大概是DefaultEndpointsProtocolhttps;AccountNamexxx;AccountKeyxxx;EndpointSuffixcore.chinacloudapi.cn国内版或者core.windows.net国际版。我建议代码里不用连接字符串因为里面含账户密钥一旦泄露等于把整个存储账户的管理员权限交出去了。另一种更推荐的姿势是用StorageAccountKeyCredential或者基于 Azure Identity 的托管身份认证。基础用法如下from azure.storage.blob import BlobServiceClient # 方式一连接字符串适合本地快速验证 conn_str DefaultEndpointsProtocolhttps;AccountNamexxx;AccountKeyxxx;EndpointSuffixcore.windows.net blob_service_client BlobServiceClient.from_connection_string(conn_str) # 方式二账户名 密钥密钥从环境变量读不要写死在代码里 from azure.storage.blob import BlobServiceClient from azure.core.credentials import AzureKeyCredential account_name myteststorage account_key os.environ[AZURE_STORAGE_ACCOUNT_KEY] blob_service_client BlobServiceClient( account_urlfhttps://{account_name}.blob.core.windows.net, credentialAzureKeyCredential(account_key) )我个人强烈建议连接字符串和密钥只出现在本地调试阶段一旦进了共享开发环境马上换成环境变量或者 Azure 密钥保管库。公司里发生过不止一次因为代码里硬编码连接字符串Git 仓库一泄露整个存储账户被人清空的事故。别问我怎么知道的人都是这么长大的。3.2 上传文件从文件路径、字节流和并发上传上传是 Blob 使用最频繁的操作先看最简单的完整文件上传from azure.storage.blob import BlobServiceClient blob_service_client BlobServiceClient.from_connection_string(conn_str) # 拿到容器客户端 container_client blob_service_client.get_container_client(course-files) # 把本地文件上传为 Blob with open(./intro.mp4, rb) as data: container_client.upload_blob( namevideos/2024/01/intro.mp4, datadata, blob_typeBlockBlob, overwriteTrue, # 小心这个参数后面细说 content_settingsContentSettings(content_typevideo/mp4) )这里有几个要点。文件名里的目录前缀videos/2024/01/intro.mp4就是 Blob 的完整名称斜杠不是真的目录而是名称的一部分。这种命名方式的好处是方便用前缀查询比如列出所有videos/2024/01/下的文件SDK 只需要扫描前缀匹配的 Blob。content_type 要显式设置如果你不传content_settingsBlob 默认的 Content-Type 是application/octet-stream。这意味着浏览器直接访问这个图片或视频 URL 时会弹出下载框而不是直接预览或者前端img标签拿到的是一坨乱码。显式传一个正确的 Content-Type 是基本素质上生产前一定要检查。overwrite 参数默认是 False也就是说如果同名 Blob 已存在上传会报错。这个设计很好防止覆盖事故。我曾经在脚本里没设 overwrite跑挂了一个半小时所有重复上传全部抛异常幸好没覆盖掉旧文件虚惊一场。想覆盖时手动写 True 就好但要明确意识到这个操作没有后悔药旧文件直接被新文件替代所以覆盖前最好先备份或者加版本控制。大文件上传SDK 的upload_blob会自动把大文件拆成多个块并发上传默认块大小 4MB并发数 8。所以传几个 GB 的文件不会内存炸掉——它内部用流式读取按块发送最后提交块列表服务端合并成完整 Blob。我这里不需要手动做分块只有当你需要自定义块大小或精细控制并发时才需要直接操作stage_block和commit_block_list。提示SDK 默认的重试机制是 4 次每次重试间隔指数退避。网络不稳定环境下传大文件默认配置大概率能撑住但如果是跨国传输或丢包率高的网络建议自定义RetryPolicy(retry_total6)代价是失败时等待时间更长换来更低的失败概率。3.3 下载文件按流下载而不是一次全装进内存下载最常见的错误是用download_blob().readall()把整个 Blob 读进内存。对于一个 1GB 的备份文件直接吃满 1GB 内存服务并发一上来就 OOM。正确做法是按流处理或下载到本地文件from azure.storage.blob import BlobServiceClient blob_service_client BlobServiceClient.from_connection_string(conn_str) container_client blob_service_client.get_container_client(course-files) # 下载到本地文件 with open(./downloaded.mp4, wb) as f: stream container_client.download_blob(videos/2024/01/intro.mp4) stream.readinto(f) # 或者按块读取逐 chunksize 消费避免一次性 load 全量 stream container_client.download_blob(videos/2024/01/intro.mp4) for chunk in stream.chunks(): process(chunk)第二种遍历chunks()的方式适合流式场景比如你下载的同时要做格式转换或计算哈希值一边拉一边算内存占用恒定。下载时还可以指定offset和length做范围读取比如视频截取头几秒预览、读取日志文件的最后几行都能避免传全量数据。3.4 列出 Blob分页、前缀过滤和虚拟目录列出容器里的 Blob 很容易写但数据量大时需要注意分页。默认一次只返回 5000 条results_per_page参数控制了每页条数需要用by_page()迭代器翻页from azure.storage.blob import BlobServiceClient container_client blob_service_client.get_container_client(course-files) # 列出全部 Blob自动翻页 blob_iter container_client.list_blobs(name_starts_withvideos/2024/, include[metadata, snapshots]) for blob in blob_iter: print(blob.name, blob.last_modified)name_starts_with对应之前说的前缀查询这是 Blob 在扁平命名空间里模拟“目录遍历”的唯一方式。如果不指定前缀容器里几百万个 Blob 会全部列出来非常慢。建议业务代码里必须配合前缀使用列表操作让查询范围尽可能收窄。还有一个细节include[snapshots]会把快照也列出来。快照是 Blob 某个时刻的只读副本做版本恢复时很有用但列出来了容易混淆默认不包含即可。3.5 删除 Blob 和容器删除单个 Blob 很简单container_client.delete_blob(videos/2024/01/intro.mp4)但容器删除有要求容器必须先清空所有 Blob否则删除会失败。Azure 没有“强制删除非空容器”的选项所以批量清理时要么先递归删 Blob要么在存储账户层开启“软删除”Soft Delete保护。软删除一定要开它能保留已删除的 Blob 一段时间可配置天数默认 7 天防止手滑删库。有次我们清理测试环境的脚本路径写错误删了生产容器的部分文件就是靠软删除救回来的。这个开关默认是关闭的别指望 Azure 主动保护你。4. 权限管理实战容器访问级别、共享密钥和 SAS 令牌的正确思路Blob 的权限模型大概是新手最容易翻车的地方一句话总结能匿名就别共享密钥能用 SAS 就别直接用账户密钥密钥只留给后台服务用。4.1 三种容器访问级别privateoff只有授权用户能访问默认值。blob容器内的 Blob 允许匿名读取但无法列出容器内容。container允许匿名读取容器内所有 Blob并且能列出容器内容。container级别最危险意味着任何人知道一个 URL 就能下载文件blob级别相当于只要你猜得到完整的 Blob URL 就能下载。做私有文件存储时这两者都不要选。但有个典型例外网站的静态资源图片、CSS、JS放在 Blob 上需要全互联网都能访问此时设成blob级别是合理的配合 CDN 还能保证访问速度。4.2 在代码里生成 SAS 令牌SAS共享访问签名是一种“限时钥匙”本质是一个附加在 URL 上的签名参数。你可以指定它允许的操作读、写、删、列、生效时间范围和来源 IP。最喜欢的场景是这些给前端一个带 SAS 的临时上传 URL让它直接传到 Blob不经过应用服务器中转给外部合作方一个带 SAS 的下载链接有效期设 24 小时过期就自动失效防止恶意用户批量下载私有文件因为 URL 暴露了也能限定到具体文件和期限。构造 SAS 可以直接用 SDK 的generate_blob_sasfrom datetime import datetime, timedelta from azure.storage.blob import BlobServiceClient, BlobSasPermissions, generate_blob_sas blob_service_client BlobServiceClient.from_connection_string(conn_str) blob_client blob_service_client.get_blob_client(course-files, videos/2024/01/intro.mp4) sas_token generate_blob_sas( account_nameblob_client.account_name, container_namecourse-files, blob_namevideos/2024/01/intro.mp4, account_keyaccount_key, permissionBlobSasPermissions(readTrue), expirydatetime.utcnow() timedelta(hours2) ) url_with_sas f{blob_client.url}?{sas_token} print(url_with_sas)权限字符串要尽量最小如果只是让用户看一眼视频只给 read 权限绝不给 write。即使 SAS 泄露攻击者也只能读这一个文件且有效期 2 小时。这是最小权限原则在对象存储上的实践。4.3 SAS 令牌的两个大坑坑一时区问题。SAS 的生效和过期时间基于 UTC你得用datetime.utcnow()生成如果用本地时间的datetime.now()国内用户东八区生成时差 8 小时就会出现“看得到是 2 小时过期实际 10 小时前就过期了”或者反过来的情况。排查生产事故时第一件事就先确认时间有没有对齐。坑二多个 SAS 拼接时的“?”重复。如果 Blob 的 URL 本身已经带了一个 SAS 参数再拼接时忘了把?换成解析就会出问题。SDK 生成的 URL 里一般不会带初始 SAS但你自己拼 URL 时一定要检查。4.4 托管身份是更优雅的解决方案如果 Blob 的调用方是运行在 Azure 内部的应用比如自己是 App Service 或某个云虚拟机上的服务最优雅的认证方式其实是托管身份Managed Identity。它不需要任何密钥Azure 会自动帮你管理身份凭据代码里直接向某个地址要一个 token 就行。好处日志里不会出现密钥就算代码泄露也不会泄露敏感凭据。但托管身份配置比密钥多几步建议先把前面的密钥方式跑通再逐步升级。5. 进阶玩法属性、元数据、快照和生命周期管理别让 Blob 只是个“文件筐”很多人把 Blob 当作一个远程文件系统来用上传文件、下载文件、删除文件仅此而已。但 Blob 设计之初就不是传统文件系统它是为对象存储服务的所以一些文件系统没有的能力反而是它的杀手级特性。5.1 元数据给文件贴标签替代一部分数据库每个 Blob 可以挂一堆自定义键值对叫 Metadata比如上传时记录sourceuser-upload、categorycourse-intro、teammarketing。查询时可以通过include[metadata]把这些标签带出来而不需要读取 Blob 内容。这在打标签、批量管理上能帮你省不少事比如给所有teammarketing的图片批量套 CDN 刷新策略就可以先列出元数据再筛选。上传时设置元数据from azure.storage.blob import BlobServiceClient, ContentSettings container_client blob_service_client.get_container_client(course-files) with open(./intro.mp4, rb) as f: container_client.upload_blob( namevideos/2024/01/intro.mp4, dataf, metadata{category: course-intro, team: marketing, uploadedBy: system} )注意 Metadata 的键和值都必须是字符串类型不能混。想用整数就转成字符串再存。5.2 快照文件的“后悔药”快照是 Blob 在某个时间点的只读副本创建快照不复制数据块成本很低。修改或删除原 Blob 不会影响已创建的快照。所以做定期备份时常见做法是每天凌晨给关键 Blob 拍个快照保留最近 N 天超出自动删。blob_client blob_service_client.get_blob_client(course-files, important_backup.bak) snapshot blob_client.create_snapshot() print(snapshot[snapshot]) # 这个时间戳就是快照标识 # 从快照恢复 blob_client_from_snapshot blob_service_client.get_blob_client( course-files, important_backup.bak, snapshotsnapshot[snapshot] ) restored_data blob_client_from_snapshot.download_blob().readall()快照的删除是独立的恢复用的就是“从快照读取一遍再重新上传一遍”的思路看起来笨但确实安全。5.3 生命周期规则自动瘦身减少存储成本刚才提过生命周期管理我强烈建议每个生产容器都配一条。即便是开发环境也经常遇到测试数据堆积几个月没人清理的情况白白烧存储费。规则可以按“前缀”或“Blob 类型”过滤比如{ rules: [ { name: deleteOldLogs, enabled: true, type: Lifecycle, definition: { actions: { baseBlob: { delete: { daysAfterModificationGreaterThan: 30 } } }, filters: { blobTypes: [ blockBlob ], prefixMatch: [ logs/ ] } } } ] }这个规则会在 Blob 修改后超过 30 天时把它删除。注意这里按“最后修改时间”不是创建时间所以你每次重新上传覆盖同一个名称的 Blob生命周期都会重新计时。配好规则后日常就不用天天盯着日志目录清理了。6. 实际项目里发生的三个典型故障以及排查思路最后分享三个真实项目里遇到的故障。前两个是配置问题第三个是设计问题希望你看完能少走点弯路。6.1 SAS 过期时间错位视频播放突然 403有一次测试反馈线上课程视频播放偶发打不开浏览器控制台报 403 Forbidden。排查时发现前端播放器使用的是带 SAS 的 URL而 SAS 是后端用一个“过期时间本地时钟”生成的。后端服务器的系统时间比真实时间快了约 20 分钟导致生成的 SAS 从后端角度看还有效但 Azure 服务端校验实际时间时已经过期于是一部分请求 403一部分请求还正常。解决方法是统一改用时区服务同步时间并强制所有 SAS 的 start/expiry 用 UTC。从那以后我写 SAS 时都以 UTC 为唯一标准绝不信任部署机器的本地时间。6.2 上传超时默认超时时间远不够大文件项目里有个功能是让用户上传 100MB - 2GB 的教学视频。开发环境网络好一切正常上线一段时间后陆续有较大文件上传失败错误信息是ServiceRequestError或OperationTimeoutError。查了半天才发现SDK 默认单个请求超时时间是 20 秒而大文件上传要做分块每块 4MB 也可能受网络带宽限制导致单块传输超过 20 秒。我们最后在客户端把connection_timeout和read_timeout调大并开启 SDK 的智能分块逻辑。这个教训说明预览连通性和生产环境大带宽之间差距很大别用开发环境来验证超时配置。from azure.storage.blob import BlobServiceClient client BlobServiceClient( https://myteststorage.blob.core.windows.net, credentialAzureKeyCredential(account_key), connection_timeout60, read_timeout60 )6.3 并发写同一路径后写覆盖先写数据丢了都不知道有一次排查线上文件缺失发现并行上传用户头像时两个用户同时上传到同一路径avatars/123.png后完成的请求直接把先前的覆盖了。代码本身没报错但业务逻辑却把 A 的头像换成了 B 的头像。问题的本质是没有用“条件写入”机制——Azure Blob 支持在写入时设置If-None-Match之类的条件如果条件不满足就返回错误。我们的业务要求是“同一个路径只允许一个用户写谁先写谁拥有”改成先创建空 Blob 占位、有人抢占就检测到冲突才彻底解决。如果你的场景是多用户并发上传、各自独立的路径比如user-{id}/avatar.png基本没问题但如果路径由业务逻辑拼接而非用户唯一 ID 决定一定要想清楚并发覆盖的可能性。from azure.storage.blob import BlobServiceClient container_client blob_service_client.get_container_client(course-files) # 带条件的上传仅当目标不存在时才上传 with open(./avatar.png, rb) as f: container_client.upload_blob( nameavatars/123.png, dataf, overwriteFalse, # 关键不允许覆盖 if_none_match* )if_none_match*的含义是“只有当目标 Blob 不存在时写入”否则触发错误。这个特性最适合实现“抢占写”或“唯一写”逻辑。Blob Storage 从入门到能稳定跑生产不算复杂但“基本用法”四个字绝对不止上传下载这么简单。我现在的习惯是每趟一个新项目先把权限模型画出来再定命名规范最后才写代码。把前面这些细节都做到位后续线上问题会少一大半。如果你刚开始接触建议从创建一个测试存储账户开始亲手传一个文件、生成一个 SAS 链接、看一次生命周期规则生效比读十篇文档都管用。 
长河君 · 2026/10/13 18:48:44 · 阅读 1.2k Azure Blob Storage实战指南：从上传下载到权限与成本优化
第一次接触 Azure Blob Storage 的时候我其实挺不屑的一个对象存储服务官方文档翻来覆去就是“创建账户、创建容器、上传文件、下载文件”这四板斧感觉比操作本地文件夹还简单能有什么坑直到后来在某个在线教育项目里要把几十万份课程视频、课件PDF和学员头像全部迁到 Blob 上才发现所谓“基本用法”背后还藏着一堆文档没写透的东西——连接字符串放哪最容易泄露、容器访问级别设错了会裸奔、SAS 令牌过期时间算不对导致生产故障、并发上传同一路径会发生什么这些都是实际跑起来才撞上的问题。这篇文章就围绕 Azure Blob Storage 的日常使用场景把从建账户到写代码上传下载、再到权限取舍的完整链路捋一遍。内容偏实战适合刚接手 Azure 项目、想快速把 Blob 用起来的开发者也适合那些已经用了一阵子但总感觉某些行为“怪怪的”的朋友。放心我不会粘贴大段官方文档只讲我试过、踩过、验证过的东西。1. 先从一张“档案柜”图看懂 Blob 的三层结构Azure Blob Storage 的宣传语总爱讲“无限扩展、高可用、对象存储”听起来很玄。但说白了它的数据组织方式和线下实体档案柜几乎没有区别档案室里有多个柜子每个柜子里有多个文件夹文件夹里装着一份份文件。对应到 Blob 上就是“存储账户 / 容器 / Blob”这三层。存储账户Storage Account是顶层单位相当于整个档案室。你在里面设置地域、冗余策略、访问层这些全局属性所有 Blob 数据都住在这个账户下。一个账户可以开很多个容器Container容器相当于档案柜主要作用是给 Blob 划定命名空间和权限边界。最底层的 Blob 才是真正存储的数据对象它本身就是一个二进制文件可以是一个 JPEG 图片、一个 MP4 视频、一段日志文本甚至是一个数据库备份文件Azure 不关心内容是什么只当它是字节流。这里有个初学者最容易忽略的细节Blob 的“目录”其实是不存在的。你看到container/videos/2024/01/course.mp4这种路径看起来有层级实际只是 Blob 的名称里包含了斜杠字符而已。容器里面是一个扁平的命名空间所有 Blob 名称都是平铺存储的。“虚拟目录”这个概念是 SDK 和 Azure Portal 为了人眼友好做出来的假象。这意味着你在代码里没法直接“进入某个目录”要么列出所有名称带指定前缀的 Blob要么直接按完整名称定位。Blob 本身又分三种类型Block Blob块 Blob、Append Blob追加 Blob、Page Blob页 Blob。日常 95% 的场景用块 Blob 就对了它适合存储静态文件和媒体文件上传时把大文件拆成小块分别传输失败后只需要重传失败的小块追加 Blob 适合写日志这类“只往后加”的数据流页 Blob 是给虚拟硬盘文件用的优化了随机读写能力。做文件存储的朋友直接用块 Blob别多看另外两个等真需要了再学也不迟。存储账户Storage Account └── 容器Container——相当于逻辑分组 └── Blob——例如 videos/2024/01/course.mp4 实际名称Name: videos/2024/01/course.mp4 元数据Metadata: 键值对例如 标题课程介绍 属性Properties: ContentType、ContentLength 等我第一次建容器的时候很迷惑容器名称居然要求小写字母、数字和连字符而且不能以连字符开头。这跟 Blob 名称的命名规则不一样Blob 名称几乎可以放任何字符包括中文和空格只要你做好 URL 编码。建议项目里统一用英文小写 连字符给容器起名Blob 名称则保持原有文件名查询方便也避免了一堆转义问题。三层结构整明白了接下来就是怎么把这个档案柜搬进代码里。2. 创建存储账户和容器时别急着点“创建”先想清楚冗余和访问层很多时候我们用 Azure 是直接抄文档写的命令账户能建出来、代码能跑通就觉得完事了。但存储账户的创建环节有两项配置会在后续几个月里持续影响你的账单和可用性创建后虽然部分可改改起来却伤筋动骨。第一个是冗余策略。默认的 LRS本地冗余存储会把数据复制到同一个数据中心内的三个副本成本最低但整个数据中心挂了数据也就没了。如果在做生产项目、尤其是数据不能丢的业务建议至少用 ZRS区域冗余存储它会把副本分布到同一个区域内的三个可用区可用性比 LRS 高一个量级。至于 GRS 和 GZRS会把数据复制到配对区域适合做跨地域灾难恢复但读取故障区域的副本是只读的别指望当双活。我的习惯是生产环境选 ZRS开发测试环境用 LRS省下的钱拿去买奶茶不香吗冗余策略创建之后不能直接更改只能迁移所以想清楚再下手。第二个是访问层Access Tier。每个存储账户都有默认访问层热Hot或冷Cool。热访问层适合频繁读写的数据存储单价高但访问单价低冷访问层存储单价便宜但每次读写都要额外付访问费。这条对应到 Blob 层面还有更细粒度单个 Blob 也能单独设置访问层热/冷/归档。归档层最便宜但把归档文件重新变为可读状态需要等待数小时到几十小时。放到真实场景里有个朋友做过一个图片托管系统客户上传的图片未来 30 天会被频繁访问之后访问量骤降。他没做任何分层策略全部数据躺在热层月末账单出来直接傻眼。正确做法是用生命周期管理策略比如“创建后 30 天转为冷层90 天后转为归档层”这在 Azure Portal 的“生命周期管理”里配置一条规则就能搞定不需要写代码。{ rules: [ { name: coolAfter30Days, enabled: true, type: Lifecycle, definition: { actions: { baseBlob: { tierToCool: { daysAfterModificationGreaterThan: 30 }, tierToArchive: { daysAfterModificationGreaterThan: 90 } } }, filters: { blobTypes: [ blockBlob ], prefixMatch: [ images/ ] } } } ] }不过这个配置有几个容易忽略的坑生命周期规则不会对 30 天内有过访问修改的 Blob 生效这里判定的不是“读取次数”而是最后修改时间另外规则不是实时的Azure 一般每天跑一次所以账单变化会迟几天。设成归档层之后如果用户想要下载这个文件得先操作“解除冻结”这个等待时间必须提前告诉业务方不然线上就会出现文件点不动、用户疯狂提工单的尴尬场景。容器本身创建就简单了Azure CLI 一条命令的事但别忘了同时设置容器访问级别az storage container create \ --name course-files \ --account-name myteststorage \ --account-key your-key \ --public-access off这段命令里我故意把--public-access写成 off这是最安全的选择。很多教程为了演示方便会写container或blob让容器内所有 Blob 都能匿名访问。我的建议是默认永远选 off永不公开。确实需要对外分享文件时用 SAS 令牌去控制有效期和权限后面章节会细讲为什么。3. 代码实操用 Python SDK 走一遍上传、下载、列出和删除账户建好了容器有了接下来就是写代码。Azure 官方提供了很多语言的 SDKJava、Python、Node、Go 都有。我平时 Python 用得多下面的例子基于azure-storage-blob这个包版本用 12.x 起步老版 2.x 已经废弃网上搜到的旧教程会让你踩坑认准新版 SDK 的 API 风格。3.1 安装和连接到存储账户pip install azure-storage-blob连接方式有两种主流姿势。一种是直接拿连接字符串Connection String在 Azure Portal 的“访问密钥”里能看到格式大概是DefaultEndpointsProtocolhttps;AccountNamexxx;AccountKeyxxx;EndpointSuffixcore.chinacloudapi.cn国内版或者core.windows.net国际版。我建议代码里不用连接字符串因为里面含账户密钥一旦泄露等于把整个存储账户的管理员权限交出去了。另一种更推荐的姿势是用StorageAccountKeyCredential或者基于 Azure Identity 的托管身份认证。基础用法如下from azure.storage.blob import BlobServiceClient # 方式一连接字符串适合本地快速验证 conn_str DefaultEndpointsProtocolhttps;AccountNamexxx;AccountKeyxxx;EndpointSuffixcore.windows.net blob_service_client BlobServiceClient.from_connection_string(conn_str) # 方式二账户名 密钥密钥从环境变量读不要写死在代码里 from azure.storage.blob import BlobServiceClient from azure.core.credentials import AzureKeyCredential account_name myteststorage account_key os.environ[AZURE_STORAGE_ACCOUNT_KEY] blob_service_client BlobServiceClient( account_urlfhttps://{account_name}.blob.core.windows.net, credentialAzureKeyCredential(account_key) )我个人强烈建议连接字符串和密钥只出现在本地调试阶段一旦进了共享开发环境马上换成环境变量或者 Azure 密钥保管库。公司里发生过不止一次因为代码里硬编码连接字符串Git 仓库一泄露整个存储账户被人清空的事故。别问我怎么知道的人都是这么长大的。3.2 上传文件从文件路径、字节流和并发上传上传是 Blob 使用最频繁的操作先看最简单的完整文件上传from azure.storage.blob import BlobServiceClient blob_service_client BlobServiceClient.from_connection_string(conn_str) # 拿到容器客户端 container_client blob_service_client.get_container_client(course-files) # 把本地文件上传为 Blob with open(./intro.mp4, rb) as data: container_client.upload_blob( namevideos/2024/01/intro.mp4, datadata, blob_typeBlockBlob, overwriteTrue, # 小心这个参数后面细说 content_settingsContentSettings(content_typevideo/mp4) )这里有几个要点。文件名里的目录前缀videos/2024/01/intro.mp4就是 Blob 的完整名称斜杠不是真的目录而是名称的一部分。这种命名方式的好处是方便用前缀查询比如列出所有videos/2024/01/下的文件SDK 只需要扫描前缀匹配的 Blob。content_type 要显式设置如果你不传content_settingsBlob 默认的 Content-Type 是application/octet-stream。这意味着浏览器直接访问这个图片或视频 URL 时会弹出下载框而不是直接预览或者前端img标签拿到的是一坨乱码。显式传一个正确的 Content-Type 是基本素质上生产前一定要检查。overwrite 参数默认是 False也就是说如果同名 Blob 已存在上传会报错。这个设计很好防止覆盖事故。我曾经在脚本里没设 overwrite跑挂了一个半小时所有重复上传全部抛异常幸好没覆盖掉旧文件虚惊一场。想覆盖时手动写 True 就好但要明确意识到这个操作没有后悔药旧文件直接被新文件替代所以覆盖前最好先备份或者加版本控制。大文件上传SDK 的upload_blob会自动把大文件拆成多个块并发上传默认块大小 4MB并发数 8。所以传几个 GB 的文件不会内存炸掉——它内部用流式读取按块发送最后提交块列表服务端合并成完整 Blob。我这里不需要手动做分块只有当你需要自定义块大小或精细控制并发时才需要直接操作stage_block和commit_block_list。提示SDK 默认的重试机制是 4 次每次重试间隔指数退避。网络不稳定环境下传大文件默认配置大概率能撑住但如果是跨国传输或丢包率高的网络建议自定义RetryPolicy(retry_total6)代价是失败时等待时间更长换来更低的失败概率。3.3 下载文件按流下载而不是一次全装进内存下载最常见的错误是用download_blob().readall()把整个 Blob 读进内存。对于一个 1GB 的备份文件直接吃满 1GB 内存服务并发一上来就 OOM。正确做法是按流处理或下载到本地文件from azure.storage.blob import BlobServiceClient blob_service_client BlobServiceClient.from_connection_string(conn_str) container_client blob_service_client.get_container_client(course-files) # 下载到本地文件 with open(./downloaded.mp4, wb) as f: stream container_client.download_blob(videos/2024/01/intro.mp4) stream.readinto(f) # 或者按块读取逐 chunksize 消费避免一次性 load 全量 stream container_client.download_blob(videos/2024/01/intro.mp4) for chunk in stream.chunks(): process(chunk)第二种遍历chunks()的方式适合流式场景比如你下载的同时要做格式转换或计算哈希值一边拉一边算内存占用恒定。下载时还可以指定offset和length做范围读取比如视频截取头几秒预览、读取日志文件的最后几行都能避免传全量数据。3.4 列出 Blob分页、前缀过滤和虚拟目录列出容器里的 Blob 很容易写但数据量大时需要注意分页。默认一次只返回 5000 条results_per_page参数控制了每页条数需要用by_page()迭代器翻页from azure.storage.blob import BlobServiceClient container_client blob_service_client.get_container_client(course-files) # 列出全部 Blob自动翻页 blob_iter container_client.list_blobs(name_starts_withvideos/2024/, include[metadata, snapshots]) for blob in blob_iter: print(blob.name, blob.last_modified)name_starts_with对应之前说的前缀查询这是 Blob 在扁平命名空间里模拟“目录遍历”的唯一方式。如果不指定前缀容器里几百万个 Blob 会全部列出来非常慢。建议业务代码里必须配合前缀使用列表操作让查询范围尽可能收窄。还有一个细节include[snapshots]会把快照也列出来。快照是 Blob 某个时刻的只读副本做版本恢复时很有用但列出来了容易混淆默认不包含即可。3.5 删除 Blob 和容器删除单个 Blob 很简单container_client.delete_blob(videos/2024/01/intro.mp4)但容器删除有要求容器必须先清空所有 Blob否则删除会失败。Azure 没有“强制删除非空容器”的选项所以批量清理时要么先递归删 Blob要么在存储账户层开启“软删除”Soft Delete保护。软删除一定要开它能保留已删除的 Blob 一段时间可配置天数默认 7 天防止手滑删库。有次我们清理测试环境的脚本路径写错误删了生产容器的部分文件就是靠软删除救回来的。这个开关默认是关闭的别指望 Azure 主动保护你。4. 权限管理实战容器访问级别、共享密钥和 SAS 令牌的正确思路Blob 的权限模型大概是新手最容易翻车的地方一句话总结能匿名就别共享密钥能用 SAS 就别直接用账户密钥密钥只留给后台服务用。4.1 三种容器访问级别privateoff只有授权用户能访问默认值。blob容器内的 Blob 允许匿名读取但无法列出容器内容。container允许匿名读取容器内所有 Blob并且能列出容器内容。container级别最危险意味着任何人知道一个 URL 就能下载文件blob级别相当于只要你猜得到完整的 Blob URL 就能下载。做私有文件存储时这两者都不要选。但有个典型例外网站的静态资源图片、CSS、JS放在 Blob 上需要全互联网都能访问此时设成blob级别是合理的配合 CDN 还能保证访问速度。4.2 在代码里生成 SAS 令牌SAS共享访问签名是一种“限时钥匙”本质是一个附加在 URL 上的签名参数。你可以指定它允许的操作读、写、删、列、生效时间范围和来源 IP。最喜欢的场景是这些给前端一个带 SAS 的临时上传 URL让它直接传到 Blob不经过应用服务器中转给外部合作方一个带 SAS 的下载链接有效期设 24 小时过期就自动失效防止恶意用户批量下载私有文件因为 URL 暴露了也能限定到具体文件和期限。构造 SAS 可以直接用 SDK 的generate_blob_sasfrom datetime import datetime, timedelta from azure.storage.blob import BlobServiceClient, BlobSasPermissions, generate_blob_sas blob_service_client BlobServiceClient.from_connection_string(conn_str) blob_client blob_service_client.get_blob_client(course-files, videos/2024/01/intro.mp4) sas_token generate_blob_sas( account_nameblob_client.account_name, container_namecourse-files, blob_namevideos/2024/01/intro.mp4, account_keyaccount_key, permissionBlobSasPermissions(readTrue), expirydatetime.utcnow() timedelta(hours2) ) url_with_sas f{blob_client.url}?{sas_token} print(url_with_sas)权限字符串要尽量最小如果只是让用户看一眼视频只给 read 权限绝不给 write。即使 SAS 泄露攻击者也只能读这一个文件且有效期 2 小时。这是最小权限原则在对象存储上的实践。4.3 SAS 令牌的两个大坑坑一时区问题。SAS 的生效和过期时间基于 UTC你得用datetime.utcnow()生成如果用本地时间的datetime.now()国内用户东八区生成时差 8 小时就会出现“看得到是 2 小时过期实际 10 小时前就过期了”或者反过来的情况。排查生产事故时第一件事就先确认时间有没有对齐。坑二多个 SAS 拼接时的“?”重复。如果 Blob 的 URL 本身已经带了一个 SAS 参数再拼接时忘了把?换成解析就会出问题。SDK 生成的 URL 里一般不会带初始 SAS但你自己拼 URL 时一定要检查。4.4 托管身份是更优雅的解决方案如果 Blob 的调用方是运行在 Azure 内部的应用比如自己是 App Service 或某个云虚拟机上的服务最优雅的认证方式其实是托管身份Managed Identity。它不需要任何密钥Azure 会自动帮你管理身份凭据代码里直接向某个地址要一个 token 就行。好处日志里不会出现密钥就算代码泄露也不会泄露敏感凭据。但托管身份配置比密钥多几步建议先把前面的密钥方式跑通再逐步升级。5. 进阶玩法属性、元数据、快照和生命周期管理别让 Blob 只是个“文件筐”很多人把 Blob 当作一个远程文件系统来用上传文件、下载文件、删除文件仅此而已。但 Blob 设计之初就不是传统文件系统它是为对象存储服务的所以一些文件系统没有的能力反而是它的杀手级特性。5.1 元数据给文件贴标签替代一部分数据库每个 Blob 可以挂一堆自定义键值对叫 Metadata比如上传时记录sourceuser-upload、categorycourse-intro、teammarketing。查询时可以通过include[metadata]把这些标签带出来而不需要读取 Blob 内容。这在打标签、批量管理上能帮你省不少事比如给所有teammarketing的图片批量套 CDN 刷新策略就可以先列出元数据再筛选。上传时设置元数据from azure.storage.blob import BlobServiceClient, ContentSettings container_client blob_service_client.get_container_client(course-files) with open(./intro.mp4, rb) as f: container_client.upload_blob( namevideos/2024/01/intro.mp4, dataf, metadata{category: course-intro, team: marketing, uploadedBy: system} )注意 Metadata 的键和值都必须是字符串类型不能混。想用整数就转成字符串再存。5.2 快照文件的“后悔药”快照是 Blob 在某个时间点的只读副本创建快照不复制数据块成本很低。修改或删除原 Blob 不会影响已创建的快照。所以做定期备份时常见做法是每天凌晨给关键 Blob 拍个快照保留最近 N 天超出自动删。blob_client blob_service_client.get_blob_client(course-files, important_backup.bak) snapshot blob_client.create_snapshot() print(snapshot[snapshot]) # 这个时间戳就是快照标识 # 从快照恢复 blob_client_from_snapshot blob_service_client.get_blob_client( course-files, important_backup.bak, snapshotsnapshot[snapshot] ) restored_data blob_client_from_snapshot.download_blob().readall()快照的删除是独立的恢复用的就是“从快照读取一遍再重新上传一遍”的思路看起来笨但确实安全。5.3 生命周期规则自动瘦身减少存储成本刚才提过生命周期管理我强烈建议每个生产容器都配一条。即便是开发环境也经常遇到测试数据堆积几个月没人清理的情况白白烧存储费。规则可以按“前缀”或“Blob 类型”过滤比如{ rules: [ { name: deleteOldLogs, enabled: true, type: Lifecycle, definition: { actions: { baseBlob: { delete: { daysAfterModificationGreaterThan: 30 } } }, filters: { blobTypes: [ blockBlob ], prefixMatch: [ logs/ ] } } } ] }这个规则会在 Blob 修改后超过 30 天时把它删除。注意这里按“最后修改时间”不是创建时间所以你每次重新上传覆盖同一个名称的 Blob生命周期都会重新计时。配好规则后日常就不用天天盯着日志目录清理了。6. 实际项目里发生的三个典型故障以及排查思路最后分享三个真实项目里遇到的故障。前两个是配置问题第三个是设计问题希望你看完能少走点弯路。6.1 SAS 过期时间错位视频播放突然 403有一次测试反馈线上课程视频播放偶发打不开浏览器控制台报 403 Forbidden。排查时发现前端播放器使用的是带 SAS 的 URL而 SAS 是后端用一个“过期时间本地时钟”生成的。后端服务器的系统时间比真实时间快了约 20 分钟导致生成的 SAS 从后端角度看还有效但 Azure 服务端校验实际时间时已经过期于是一部分请求 403一部分请求还正常。解决方法是统一改用时区服务同步时间并强制所有 SAS 的 start/expiry 用 UTC。从那以后我写 SAS 时都以 UTC 为唯一标准绝不信任部署机器的本地时间。6.2 上传超时默认超时时间远不够大文件项目里有个功能是让用户上传 100MB - 2GB 的教学视频。开发环境网络好一切正常上线一段时间后陆续有较大文件上传失败错误信息是ServiceRequestError或OperationTimeoutError。查了半天才发现SDK 默认单个请求超时时间是 20 秒而大文件上传要做分块每块 4MB 也可能受网络带宽限制导致单块传输超过 20 秒。我们最后在客户端把connection_timeout和read_timeout调大并开启 SDK 的智能分块逻辑。这个教训说明预览连通性和生产环境大带宽之间差距很大别用开发环境来验证超时配置。from azure.storage.blob import BlobServiceClient client BlobServiceClient( https://myteststorage.blob.core.windows.net, credentialAzureKeyCredential(account_key), connection_timeout60, read_timeout60 )6.3 并发写同一路径后写覆盖先写数据丢了都不知道有一次排查线上文件缺失发现并行上传用户头像时两个用户同时上传到同一路径avatars/123.png后完成的请求直接把先前的覆盖了。代码本身没报错但业务逻辑却把 A 的头像换成了 B 的头像。问题的本质是没有用“条件写入”机制——Azure Blob 支持在写入时设置If-None-Match之类的条件如果条件不满足就返回错误。我们的业务要求是“同一个路径只允许一个用户写谁先写谁拥有”改成先创建空 Blob 占位、有人抢占就检测到冲突才彻底解决。如果你的场景是多用户并发上传、各自独立的路径比如user-{id}/avatar.png基本没问题但如果路径由业务逻辑拼接而非用户唯一 ID 决定一定要想清楚并发覆盖的可能性。from azure.storage.blob import BlobServiceClient container_client blob_service_client.get_container_client(course-files) # 带条件的上传仅当目标不存在时才上传 with open(./avatar.png, rb) as f: container_client.upload_blob( nameavatars/123.png, dataf, overwriteFalse, # 关键不允许覆盖 if_none_match* )if_none_match*的含义是“只有当目标 Blob 不存在时写入”否则触发错误。这个特性最适合实现“抢占写”或“唯一写”逻辑。Blob Storage 从入门到能稳定跑生产不算复杂但“基本用法”四个字绝对不止上传下载这么简单。我现在的习惯是每趟一个新项目先把权限模型画出来再定命名规范最后才写代码。把前面这些细节都做到位后续线上问题会少一大半。如果你刚开始接触建议从创建一个测试存储账户开始亲手传一个文件、生成一个 SAS 链接、看一次生命周期规则生效比读十篇文档都管用。