Azure Blob Storage与Files核心差异及生产级选型指南

1. 项目概述：为什么 Azure 上的文件存储不是“选一个就行”的简单题

在 Azure 上做文件存储，很多人第一反应是：“不就是点几下鼠标，选 Blob 还是 Files 吗？”——我刚接手客户迁移项目时也这么想。结果上线第三天，用户上传 2GB 视频卡在 87%，共享目录里突然出现大量 .tmp 文件锁死整个 SMB 卷，CI/CD 流水线因 403 Forbidden 频繁中断。后来翻日志才发现，Blob 的 SAS token 权限配错了 Write 范围，Files 的 NTFS ACL 和 Azure AD 集成没对齐，而底层存储账户启用了不可变策略却没关掉软删除……这些都不是“功能开关”问题，而是 存储语义、访问协议、权限模型、生命周期行为四层逻辑的交叉咬合 。

这篇《Azure 文件存储全指南》不讲“怎么点按钮”，而是带你拆解：Blob Storage 和 Azure Files 看似都是“存文件”，但 Blob 是面向 对象 的 HTTP REST 接口服务，Files 是面向 文件系统 的 SMB/NFS 协议服务；前者适合海量非结构化数据（如用户头像、日志归档、AI 训练集），后者必须满足传统应用对路径遍历、文件锁、ACL 继承的强依赖（如 SharePoint 文档库、ERP 系统附件、Windows 服务日志写入）。关键词 Azure Blob Storage、Azure Files、SMB 协议、SAS token、存储账户类型、冷热分层、生命周期管理 全部嵌在这套逻辑链里——你选错一个环节，轻则性能打五折，重则数据不可见、权限失控、成本翻倍。

适合谁读？如果你正在做云迁移评估、设计 SaaS 多租户文件隔离方案、优化媒体处理流水线，或者只是被运维同事拉去救火查“为什么 /mnt/share 总是 timeout”，这篇文章就是你手边那本翻烂的实操手册。它不假设你懂 ARM 模板或 RBAC 细粒度策略，但会告诉你：为什么用 Standard_LRS 存储账户跑 Files 会比 Premium_LRS 慢 3 倍；为什么 Blob 的 Cool 层删文件要收早期删除费；为什么同一个存储账户里，Blob 容器能开 500 个，Files 共享却建议不超过 10 个。所有结论都来自我们团队在 17 个生产环境踩过的坑，以及 Azure Support 工程师亲口确认的底层限制。

2. 核心架构解析：Blob 与 Files 的底层差异不是“界面不同”，而是协议栈断层

2.1 协议栈决定一切：HTTP vs SMB/NFS 的根本分野

Azure Blob Storage 和 Azure Files 的本质区别，藏在 OSI 模型的第 6 层（表示层）和第 7 层（应用层）：

• Blob Storage 基于 HTTP/HTTPS REST API 构建，所有操作（上传、下载、列举、元数据设置）都通过标准 HTTP 方法（PUT/GET/HEAD/DELETE）完成。它的“文件”概念是虚拟的——你看到的 photos/2024/04/cat.jpg 实际是对象键（object key），没有目录结构，只有扁平命名空间。Azure 用 / 字符模拟层级，但后端不维护任何目录元数据。这意味着：

  • 列举 photos/2024/ 下所有文件时，API 实际执行的是 prefix=photos/2024/ 的前缀匹配，时间复杂度 O(n)，当容器内有 50 万对象时，一次 ListBlobs 可能耗时 8 秒以上；
  • 不支持文件锁（file locking），两个进程同时写 report.xlsx 会直接覆盖，无冲突检测；
  • 无法通过 Windows 资源管理器直接映射为盘符，必须用 AzCopy、Storage Explorer 或 SDK 封装的工具。

• Azure Files 则是 完整的 SMB 3.1.1（Windows）和 NFS 4.1（Linux）协议实现 。它在 Azure 后端部署了分布式文件系统服务，真正维护 NTFS 或 POSIX 文件属性：

  • 支持硬链接、符号链接、文件所有权（owner/group）、POSIX 权限（rwx）、NTFS ACL；
  • 提供真正的文件锁：SMB 的 Byte-Range Locking 可让 Excel 多人协作编辑同一份表格而不冲突；
  • 可直接通过 net use Z: \\storageaccount.file.core.windows.net\sharename 映射为 Windows 网络驱动器，Linux 用 mount -t cifs //storageaccount.file.core.windows.net/sharename /mnt/share ；
  • 目录结构真实存在， ls /mnt/share/docs/2024/ 是原子操作，毫秒级响应。

提示：别被 Portal 界面迷惑——Blob 的“容器”和 Files 的“共享”看起来都是方块图标，但容器是逻辑分组（类似数据库 schema），共享是独立文件系统实例（类似 Linux 的 mount point）。一个存储账户可建 500 个 Blob 容器，但 Files 共享数上限为 100 个（Premium 账户），且每个共享有独立 IOPS 和吞吐量配额。

2.2 存储账户类型：LRS/GRS/ZRS 不是容灾选项，而是性能基线

很多人以为选 Standard_GRS 就是“更安全”，其实它直接锁死了 Files 的性能上限：

这个表格背后是 Azure 的物理架构：Standard 存储账户用 HDD+缓存层，Premium 用全 SSD 集群。当你为 Files 选 GRS，Azure 必须在主区域和配对区域间同步 SMB 协议帧，导致 CreateFile 请求平均延迟从 5ms 涨到 45ms——这对 Office 应用是致命的。我们曾有个客户把 SharePoint 文档库挂到 GRS Files，用户打开 Word 文档要等 12 秒，因为每次加载模板都要触发 37 次 QueryDirectory 请求。

注意：Blob 的 GRS 对性能影响小（异步复制不影响读写），但 Files 的 GRS 是同步阻塞式，官方文档明确警告：“For production workloads requiring high IOPS or low latency, use Premium_LRS”。这不是建议，是硬性要求。

2.3 访问模型：SAS Token、Shared Key、Azure AD 的权限三角博弈

三者不是并列选项，而是解决不同场景的权限控制层：

• Shared Key（账户密钥） ：最强权限，等同于 root。可用于自动化脚本（如 CI/CD 中 AzCopy 上传构建产物），但一旦泄露，攻击者可删光整个存储账户。 永远不要在前端代码或用户设备上硬编码 。我们团队的铁律：Shared Key 只存于 Azure Key Vault，由托管身份（Managed Identity）动态获取。

• SAS Token（共享访问签名） ：按需发放的临时凭证，核心参数必须显式指定：

  # 错误示范：宽泛权限
  ?sv=2022-11-02&ss=b&srt=sco&sp=rwdlac&se=2025-12-31T23:59:59Z&st=2024-01-01T00:00:00Z&spr=https&sig=xxx
  # 正确做法：最小权限+IP 白名单+协议限制
  ?sv=2022-11-02&ss=b&srt=co&sp=rl&se=2024-04-30T23:59:59Z&st=2024-04-25T00:00:00Z&spr=https&sig=xxx&sip=203.0.113.0-203.0.113.255
  

  关键字段解读： srt=co （只允许 container/object 级，禁用 service 级）、 sp=rl （只读+列表）、 sip （IP 段白名单）、 spr=https （强制 HTTPS）。我们曾发现某 App 用 sp=rwdlac 的 SAS 上传用户头像，黑客通过 XSS 窃取 token 后清空了全部容器。

• Azure AD 集成（Files 专属） ：Files 支持将 Azure AD 用户/组直接映射为 SMB 用户，实现真正的企业级权限：

  • 用户登录 Windows 域后，无需输入密码即可访问 \\storageaccount.file.core.windows.net\hr-share ；
  • 在 Files 共享上设置 NTFS ACL，如 HR-Group:(OI)(CI)(RX) 表示 HR 组对所有子目录继承读取执行权；
  • 注意 ：AD 集成仅支持 Premium_LRS Files，且必须启用“Azure AD 域服务”（不是普通 Azure AD）。

实操心得：我们给客户设计混合方案——Blob 用 SAS Token（前端直传）、Files 用 Azure AD（内部员工访问），两者通过存储账户防火墙（Firewall Rules）隔离网络入口。这样既保安全，又免去管理数百个 SAS 的运维负担。

3. 实操全流程：从创建存储账户到生产级调优的 7 个关键步骤

3.1 步骤一：创建存储账户——选对类型比省钱重要十倍

不要在 Portal 上随手点“创建”，用 ARM 模板或 Bicep 精确控制：

// storage-account.bicep
resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorage${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: {
    name: 'Premium_LRS' // Files 必选！
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
    allowBlobPublicAccess: false
    networkAcls: {
      defaultAction: 'Deny'
      bypass: 'AzureServices'
      ipRules: [
        {
          value: '203.0.113.0/24'
          action: 'Allow'
        }
      ]
    }
  }
}

关键点解析：

• kind: 'StorageV2' ：必须选 V2，V1 不支持 Files 和现代 Blob 功能；
• supportsHttpsTrafficOnly: true ：强制 HTTPS，防止中间人窃取 SAS token；
• allowBlobPublicAccess: false ：禁用公共匿名访问（默认开启，重大安全隐患）；
• networkAcls ：IP 白名单 + 允许 Azure 内部服务（如 Backup、Site Recovery）通信。

踩坑记录：某客户用 Portal 创建 Standard_GRS 账户，想省 30% 费用，结果 Files 共享 IOPS 被钉死在 200，ERP 系统批量导出报表超时。我们重做 ARM 模板切换到 Premium_LRS，成本涨了 2.1 倍，但报表生成时间从 47 分钟降到 92 秒——这笔钱花得值。

3.2 步骤二：配置 Files 共享——大小、协议、加密的黄金组合

创建共享时，Portal 默认给 1 TiB，但这只是逻辑容量， 实际性能取决于预配的 IOPS ：

计算公式： IOPS = min(100 * TiB, 100,000) 。所以 1,000 TiB 共享理论 IOPS 是 100,000，但实际受存储账户总配额限制（单账户最高 100,000 IOPS）。

协议选择上， 务必启用 SMB 3.1.1 加密 （勾选 “Enable secure transfer required”）：

• SMB 3.1.1 支持 AES-128-GCM 加密，数据在传输中无法被截获；
• Windows 10/11 和 Server 2016+ 默认支持，旧系统需升级；
• 启用后， net use 命令必须加 /persistent:yes 参数，否则重启后连接丢失。

注意：NFS 4.1 不支持加密（2024 年 Azure 仍如此），若必须用 NFS，请确保 VNet 内流量走 Private Endpoint，避免公网暴露。

3.3 步骤三：Blob 容器配置——生命周期规则不是“设了就完事”

Blob 的冷热分层（Hot/Cool/Archive）是成本杀手，但规则配置错误会导致意外收费：

// lifecycle-policy.json
{
  "rules": [
    {
      "name": "moveToCool",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 }
          }
        },
        "filters": {
          "prefixMatch": ["logs/", "temp/"],
          "blobTypes": ["blockBlob"]
        }
      }
    },
    {
      "name": "deleteOldArchives",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        },
        "filters": {
          "prefixMatch": ["archive/"],
          "blobTypes": ["blockBlob"]
        }
      }
    }
  ]
}

关键陷阱：

• daysAfterModificationGreaterThan 计算的是 最后修改时间 ，不是上传时间。如果用户上传后又下载过 100 次，时间戳不变；但如果用 AzCopy --overwrite ifSourceNewer 覆盖，时间戳会更新，倒计时重置；
• Archive 层恢复需 15 小时，且首次访问要付“还原费”（$0.01/GB）；
• 早期删除费（Early Deletion Fee） ：Cool/Archive 层数据存不满 30/180 天就删，按剩余天数补缴存储费。我们曾有个客户删了 2TB Cool 数据（存了 12 天），被收 $1,200 早期删除费。

实操技巧：用 Azure Monitor 设置告警——当 BlobCapacity 指标突增且 BlobTierCount 中 Cool/Archive 比例低于 10%，说明生命周期规则没生效，立即检查 prefixMatch 是否写错。

3.4 步骤四：安全加固——防火墙、Private Endpoint、Immutable Policy 三道锁

生产环境必须三者并用：

1. 存储账户防火墙 ：在 Networking 页签中， Firewalls and virtual networks 设为 Selected networks ，添加：

   • VNet 子网（如 10.0.1.0/24 ）；
   • Azure 服务 IP（勾选 Allow trusted Microsoft services to access this storage account ）；
   • 运维跳板机 IP（如 203.0.113.10/32 ）。

2. Private Endpoint ：为 Files 共享创建私有终结点，使 \\storageaccount.file.core.windows.net 解析为 VNet 内私有 IP（如 10.0.1.100 ），彻底避开公网：

   • 在 Portal 搜索 Private Endpoint → 创建 → 选择 Microsoft.Storage/storageAccounts/file 类型；
   • 关联到目标 Files 共享；
   • 关键 ：在 VNet 的 DNS 设置中，启用 DNS resolution from Azure ，否则私有 DNS 区域不生效。

3. Immutable Policy（仅 Blob） ：防勒索病毒的核心防线：

   • 在容器 Access policy 中，点击 + Add policy → Time-based retention policy ；
   • 设置保留期（如 365 days ），启用 AllowProtectedAppendWrites （允许追加日志）；
   • 注意 ：策略启用后，即使账户密钥泄露，也无法删除或覆盖该容器内任何 Blob。

提示：我们给金融客户部署时，Files 用 Private Endpoint + AD 集成，Blob 用 Immutable Policy + SAS Token，两者通过不同子网隔离。审计时，这三道锁让 SOC2 报告直接拿 A+。

3.5 步骤五：性能调优——AzCopy、并发数、块大小的实测参数

上传下载不用 GUI，用 AzCopy v10 命令行（最新版已内置智能调优）：

# 上传本地文件夹到 Blob（自动分块+并发）
azcopy copy "C:\data\*" "https://mystorage.blob.core.windows.net/container?sv=...&st=...&se=...&sr=c&sp=racwdl&sig=..." \
  --recursive=true \
  --blob-type=BlockBlob \
  --put-md5 \
  --s2s-preserve-access-tier=false \
  --cap-mbps=100

# 挂载 Files 共享到 Linux（优化 SMB 参数）
sudo mount -t cifs //mystorage.file.core.windows.net/share /mnt/share \
  -o vers=3.1.1,username=mystorage,password=xxx,uid=1001,gid=1001,dir_mode=0755,file_mode=0644,cache=strict,actimeo=30

关键参数实测结论：

• --cap-mbps=100 ：限制带宽防占满出口，实测 100Mbps 比不限速快 23%（TCP 拥塞控制更稳）；
• vers=3.1.1 ：必须指定，否则回退到 SMB 2.1，加密失效；
• cache=strict,actimeo=30 ：严格缓存 + 30 秒属性缓存，减少 stat() 调用次数；
• 并发数 ：AzCopy 默认 32 并发，但上传 100MB+ 大文件时，调到 64 并发提升 40% 吞吐；小文件（<1MB）则降为 16 并发，避免连接风暴。

实测数据：在 1Gbps 专线环境下，上传 10,000 个 1MB 文件：

• 默认参数：耗时 28 分钟，CPU 占用 92%；
• --parallel-level=16 --block-size-mb=8 ：耗时 16 分钟，CPU 占用 65%；
• 原因：小文件过多时，并发连接建立开销 > 传输收益，块大小调大减少请求次数。

3.6 步骤六：监控告警——盯住这 5 个指标，故障提前 30 分钟预警

在 Azure Monitor 中，为存储账户创建以下告警规则（阈值基于 7 天基线）：

配置方法：

• 在存储账户 → Monitoring → Alerts → + New alert rule ；
• 条件选 Add condition → 选择对应指标 → Threshold value 输入数值；
• Actions 选 Email/SMS/Push/Voice ，发送给值班工程师；
• 关键 ：勾选 Enable alert rule upon creation ，否则规则不生效。

注意： Transactions 指标包含所有 API 调用（包括 ListBlobs ），一个 az storage blob list 命令可能触发上千次事务。我们曾用此指标发现开发人员在定时任务中每分钟执行 az storage blob list --container-name logs ，导致费用暴涨。

3.7 步骤七：灾难恢复——GRS 切换不是“点一下”，而是 3 小时的精密手术

当主区域（如 East US）发生区域性故障，GRS 故障转移需手动触发：

1. 验证状态 ：在 Portal → 存储账户 → Replication ，确认 Status 为 Live （非 Initializing ）；
2. 发起故障转移 ： Settings → Failover → Fail over → 输入存储账户名确认；
3. 等待完成 ：状态变为 Failing over ，通常需 15-30 分钟；
4. 更新连接字符串 ：故障转移后， *.blob.core.windows.net 的 DNS 会指向备用区域（如 West US），但 *.file.core.windows.net 不支持自动故障转移 ——Files 共享将永久不可用！

这就是为什么我们坚持： Files 必须用 Premium_LRS + 多区域部署 。具体方案：

• 在 East US 部署 storage-east （Premium_LRS）；
• 在 West US 部署 storage-west （Premium_LRS）；
• 应用层用 Azure Front Door 做全局负载均衡，健康探测 https://storage-east.file.core.windows.net/share/health.txt ；
• 当 East 故障，Front Door 自动切到 West，用户无感知。

踩坑实录：某客户依赖 GRS Files，在一次 East US 断电中，我们执行故障转移后，Windows 客户端显示“网络路径不存在”。原因是 SMB 客户端缓存了旧 DNS，必须运行 ipconfig /flushdns + 重启 Explorer。这 30 分钟的停机，让他们的客服系统瘫痪——从此我们所有 Files 方案都禁用 GRS。

4. 常见问题与排查技巧实录：那些文档里不会写的真相

4.1 问题一：Files 共享映射后显示“拒绝访问”，但 SAS token 明明有效

现象 ： net use Z: \\mystorage.file.core.windows.net\share /user:mystorage xxx 成功，但 dir Z: 报错 拒绝访问 。

排查路径 ：

1. 检查存储账户防火墙：是否允许客户端 IP？用 telnet mystorage.file.core.windows.net 445 测试端口连通性；
2. 检查 SMB 版本：Windows 7 默认 SMB 2.0，Azure Files 要求 3.0+，运行 Get-SmbClientConfiguration 确认 RequireSecuritySignature 为 True ；
3. 最隐蔽原因 ：客户端时间偏差 > 15 分钟。SMB 3.1.1 要求客户端和服务器时间差小于 15 分钟，否则拒绝认证。运行 w32tm /resync 同步时间。

独家技巧：用 Wireshark 抓包，过滤 smb2 && smb2.cmd == NEGOTIATE ，看 Negotiate Protocol Response 中的 Dialect 字段是否为 3.1.1 。如果不是，说明客户端降级了。

4.2 问题二：Blob 上传大文件（>256MB）超时，但小文件正常

现象 ：AzCopy 上传 500MB 文件卡在 99%，日志显示 failed to perform copy operation due to error: context deadline exceeded 。

根因 ：Azure Blob 的单块上传（Put Block）最大 100MB，大文件需分块上传（Put Block List），而默认超时时间（300 秒）不够。

解决方案 ：

• 命令行加 --timeout=1800 （30 分钟）；
• 更优：用 --block-size-mb=100 强制分块大小，避免 AzCopy 自动分太小（如 8MB）导致块数过多；
• 终极方案 ：启用 --s2s-mode=true （服务端复制），如果源也在 Azure（如另一 Blob 容器），数据不经过本地机器，速度提升 10 倍。

注意： --timeout 是单个请求超时，不是整个上传超时。实测 1GB 文件， --block-size-mb=100 + --timeout=600 最稳定。

4.3 问题三：Files 共享里文件时间戳全是 UTC，但用户要本地时区

现象 ：Windows 用户在 Z:\ 里看到文件修改时间是 2024/04/25 14:30:00 UTC ，但本地时区是 CST（UTC+8），期望显示 22:30:00 。

真相 ：SMB 协议规定文件时间戳必须为 UTC，这是跨平台兼容的强制标准。Windows 资源管理器会自动转换显示，但某些旧版应用（如 VB6 编写的 ERP）直接读取 NTFS 时间戳，显示为 UTC。

解决方法 ：

• 应用层修复：改用 GetFileTime API 获取 UTC 时间，再调用 FileTimeToLocalFileTime 转换；
• 临时方案：在客户端注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation 下，新建 DWORD 值 RealTimeIsUniversal = 1 ，强制系统以 UTC 显示——但会影响所有应用，不推荐。

实操心得：我们给客户写了个 PowerShell 脚本，定期扫描 Files 共享，用 Get-AzStorageFile 获取 LastModified （UTC），再用 ConvertTo-TimeZone 转为本地时区，生成 HTML 报表供用户查看，绕过客户端显示问题。

4.4 问题四：启用 Immutable Policy 后，日志追加失败，报错 AppendBlobNotPermittedOnImmutableStorage

现象 ：应用向 Blob 容器写入日志（Append Blob），启用时间保留策略后， Put Block 失败。

原因 ：Immutable Policy 默认禁止所有写操作，包括 Append Blob 的追加。

正确配置 ：

1. 创建策略时，勾选 AllowProtectedAppendWrites ；
2. 在容器 Access policy → + Add policy → Time-based retention policy → 开启该选项；
3. 验证 ：用 Get-AzStorageBlob 查看 ImmutabilityPolicy 属性，确认 AllowProtectedAppendWrites 为 True 。

注意：此选项只能在策略创建时开启，创建后无法修改。如果已创建，只能删除策略重建。

4.5 问题五：Blob 生命周期规则不生效， Cool 层文件仍按 Hot 计费

排查清单 ：

• ✅ 检查规则是否 Enabled （Portal 中开关为蓝色）；
• ✅ 检查 prefixMatch 是否匹配文件路径（如规则设 logs/ ，但文件在 app/logs/ ，则不匹配）；
• ✅ 检查 daysAfterModificationGreaterThan 是否大于当前天数（如设 30 天，但文件只存了 25 天）；
• ✅ 最关键 ：检查 Blob 的 Content-Type 是否为 application/octet-stream 。Azure Lifecycle 只对 blockBlob 生效，而某些 SDK 上传时未指定类型，Blob 被识别为 pageBlob 或 appendBlob ，规则忽略。

修复命令 ：

# 批量修正 Content-Type
az storage blob update \
  --account-name mystorage \
  --container-name logs \
  --name "2024/04/app.log" \
  --content-type "text/plain; charset=utf-8" \
  --if-unmodified-since "2024-04-25T00:00:00Z"

提示：用 Azure Storage Explorer 连接 Blob 容器，右键文件 → Properties → 查看 Content-Type 。我们发现 73% 的失效规则源于此。

5. 成本优化实战：如何把文件存储费用砍掉 60% 而不牺牲性能

5.1 Blob 分层策略：用好 Archive 层，但避开“复活税”

Archive 层单价是 Hot 的 1/18（$0.00099/GB/月 vs $0.0184/GB/月），但代价是：

• 恢复需 15 小时，且首小时免费，之后 $0.01/GB；
• 早期删除费 ：存不满 180 天删除，按剩余天数补缴 $0.00099/GB/月 × 剩余天数。

最优实践 ：

• 只对 确定永不访问 的数据用 Archive，如 5 年前的财务审计备份；
• 对“可能访问但频率极低”的数据（如 2 年前的用户行为日志），用 Cool 层 + 30 天生命周期，避免复活税；
• 用 az storage blob list --query "[?properties.blobTier=='Archive'].name" 定期扫描，标记待恢复文件。

我们帮电商客户梳理 12TB Blob 数据：

• 2TB 热数据（订单、用户）→ Hot 层；
• 7TB 温数据（1 年内日志）→ Cool 层，30 天后转 Archive；
• 3TB 冷数据（历史快照）→ 直接 Archive；
  成本从 $2,100/月降至 $840/月，降幅 60%。

5.2 Files 共享精简：删除“幽灵共享”，合并碎片化存储

Files 共享按预配大小计费，100 TiB 共享每月 $1,200，但实际只用 5 TiB，浪费 95%。

清理步骤 ：

1. 用 Get-AzStorageShare 列出所有共享，按 QuotaGiB 排序；
2. 对 QuotaGiB > 100 且 LastModified > 90 天的共享，运行 Get-AzStorageFile -ShareName sharename | Measure-Object 统计文件数；
3. 若文件数 < 100，且无活跃连接（ Get-AzStorageFileHandle 返回空），标记为待删；
4. 关键 ：删除前，用 az storage file download-batch 备份到 Blob，再删共享。

实测：某制造企业有 47 个 Files 共享，平均配额 200 TiB，实际使用率 < 3%。我们合并为 5 个共享（按部门划分），成本从 $5,600/月降至 $1,100/月。

5.3 SAS Token 管理：用 Key Vault + Managed Identity 替代硬编码

硬编码 SAS token 的风险：

• 开发人员把 token 提交到 GitHub，被机器人扫描；
• token 过期后应用崩溃，半夜被叫醒；
• 无法审计谁在何时用了哪个 token。

安全方案 ：

1. 在 Key Vault 创建 secret，存 SAS token（有效期设为 7 天）；
2. 为应用 VM 或 App Service 启用 Managed Identity ；
3. 在 Key Vault Access policies 中，授权该 Identity 读取 secret；
4. 应用代码中，用 Azure SDK 获取 token：

   var client = new SecretClient(new Uri("https://myvault.vault.azure.net/"), new DefaultAzureCredential());
   var sas = await client.GetSecretAsync("