我自己也遇到了这个问题，需要更新数千个文件的 Cache-Control 标头。为了防止站点中的缓存问题，我在每次发布时将这些文件重新部署到新路径。
我能够在网上将一些不同的建议拼凑在一起，最终找到了以下解决方案，我目前使用它来部署我的一个生产应用程序。
您需要两个文件，脚本假定它们位于您计算机上的同一目录中：
- 包含容器中文件列表的文本文件（参见下面的示例）
- PowerShell 脚本
文本文件 (file-list.txt)
该文件应采用以下示例格式，并具有部署到 CDN 容器的完整文件路径。请注意，这使用正斜杠，并且不应包含容器名称，因为它将包含在脚本中。此文本文件的名称将包含在下面的 PowerShell 脚本中。
v12/app/app.js
v12/app/app.min.js
v12/app/app.min.js.map
v12/app/account/signup.js
v12/app/account/signup.min.js
... (and so on)
脚本 (cdn-cache-control.ps1)
完整的脚本如下。你需要替换 STORAGE_ACCOUNT_NAME、STORAGE_KEY 等常量，如果你有不同的版本，你可能需要更新 Azure SDK DLL 的路径。 $blobClient 也有 2 种可能的实现方式；我从在线源中重新利用了其中一些代码，而未注释的代码对我有用。
我在这里看到的和你在网上看到的主要区别在于包含$blob.FetchAttributes()。在不显式调用此方法的情况下，大多数 blob 属性（如 Content-Type、上次修改日期和其他属性）将作为空/默认值加载到内存中，然后当调用 $blob.SetProperties() 时，这些空值将清除现有的在 CDN 中，导致文件在没有 Content-Type 的情况下加载。
Add-Type -Path "C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\Microsoft.WindowsAzure.StorageClient.dll"
$accountName = "STORAGE_ACCOUNT_NAME"
$accountKey = "STORAGE_KEY"
$blobContainerName = "STORAGE_CONTAINER_NAME"
$storageCredentials = New-Object Microsoft.WindowsAzure.StorageCredentialsAccountAndKey -ArgumentList $accountName,$accountKey
$storageAccount = New-Object Microsoft.WindowsAzure.CloudStorageAccount -ArgumentList $storageCredentials,$true
#$blobClient = $storageAccount.CreateCloudBlobClient()
$blobClient = [Microsoft.WindowsAzure.StorageClient.CloudStorageAccountStorageClientExtensions]::CreateCloudBlobClient($storageAccount)
$cacheControlValue = "max-age=31556926"
echo "Setting cache control: $cacheControlValue"
Get-Content "file-list.txt" | foreach {
$blobName = "$blobContainerName/$_".Trim()
$blob = $blobClient.GetBlobReference($blobName)
$blob.FetchAttributes()
$blob.Properties.CacheControl = $cacheControlValue
$blob.SetProperties()
echo $blobName
}
很难找到有关批量设置 Cache-Control 标头的信息，但我已经为多个生产版本运行此脚本并取得了巨大成功。我也验证了标头的配置，并定期针对我的网站运行 Google 的 PageSpeed Insights 以进行验证。