注释
此版本不是本文的最新版本。 要查看当前版本,请参阅本文的.NET 9 版本。
警告
此版本的 ASP.NET Core 不再受支持。 有关详细信息,请参阅 .NET 和 .NET Core 支持策略。 要查看当前版本,请参阅本文的.NET 9 版本。
本文介绍如何托管和部署 Blazor WebAssembly 应用。
- 将 Blazor 应用、其依赖项及 .NET 运行时并行下载到浏览器。
- 应用将在浏览器线程中直接执行。
本文涉及的部署方案是这样的:Blazor 应用放置在静态托管 Web 服务器或服务上,.NET 不用于为 Blazor 应用提供服务。 此策略在 IIS、Azure 服务、Apache、Nginx 和 GitHub Pages 的此节点中的“ 独立部署 ”部分和其他文章中介绍。
支持以下部署策略:
- Blazor 应用由 ASP.NET Core 应用提供服务。 使用 ASP.NET Core 进行托管部署部分中介绍了此策略。
- Blazor 应用位于静态托管 Web 服务器或服务中,其中未使用 .NET 对 Blazor 应用提供服务。 独立部署部分介绍了此策略,包括有关将 Blazor WebAssembly 应用作为 IIS 子应用托管的信息。
- ASP.NET Core 应用托管多个 Blazor WebAssembly 应用。 有关详细信息,请参阅多个托管的 ASP.NET Core Blazor WebAssembly 应用。
子域和 IIS 子应用程序托管
子域托管不需要应用的特殊配置。 无需将应用基路径(<base>
中的 wwwroot/index.html
标记)配置为在子域托管应用。
IIS 子应用程序托管的确需要设置应用基路径。 有关 IIS 子应用程序托管的进一步指导的详细信息和交叉链接,请参阅托管和部署 ASP.NET 核心 Blazor。
减少某些移动设备浏览器的最大堆大小
当生成在客户端上运行的 Blazor 应用(.Client
的 Blazor Web App 项目或独立的 Blazor WebAssembly 应用)并面向移动设备浏览器(尤其是 iOS 上的 Safari)时,可能需要使用 MSBuild 属性 EmccMaximumHeapSize
减少应用的最大内存。 默认值为 2,147,483,648 字节,该值可能太大,如果应用尝试分配更多内存,而浏览器无法授予,则可能会导致应用崩溃。 以下示例将 Program
文件中的值设置为 268,435,456 字节:
生成面向移动设备浏览器(尤其是 iOS 上的 Safari)的 Blazor WebAssembly 应用时,可能需要使用 MSBuild 属性 EmccMaximumHeapSize
减少应用的最大内存。 默认值为 2,147,483,648 字节,该值可能太大,如果应用尝试分配更多内存,而浏览器无法授予,则可能会导致应用崩溃。 以下示例将 Program
文件中的值设置为 268,435,456 字节:
<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>
有关 Mono/WebAssembly MSBuild 属性和目标的详细信息,请参阅 WasmApp.Common.targets
(dotnet/runtime
GitHub 存储库)。
.NET 程序集的 Webcil 打包格式
Webcil 是一种适用于 .NET 程序集的 Web 友好打包格式,旨在支持在限制性网络环境中使用 Blazor WebAssembly。 Webcil 文件使用标准 WebAssembly 包装器,其中程序集部署为使用标准 .wasm
文件扩展名的 WebAssembly 文件。
发布 Blazor WebAssembly 应用时,Webcil 是默认打包格式。 若要禁用 Webcil,请在应用的项目文件中设置以下 MS Build 属性:
<PropertyGroup>
<WasmEnableWebcil>false</WasmEnableWebcil>
</PropertyGroup>
自定义加载启动资源的方式
自定义如何使用 loadBootResource
API 加载启动资源。 有关详细信息,请参阅 ASP.NET Core Blazor 启动。
压缩
发布 Blazor WebAssembly 应用时,将在发布过程中对输出内容进行静态压缩,从而减小应用的大小,并免去运行时压缩的开销。 使用以下压缩算法:
Blazor 依赖于主机提供适当的压缩文件。 托管 Blazor WebAssembly 独立应用时,可能需要额外的工作来确保提供静态压缩文件:
Blazor 依赖于主机提供适当的压缩文件。 使用 ASP.NET Core 托管的 项目时,主机项目能够执行内容协商并提供静态压缩文件。 托管 Blazor WebAssembly 独立应用时,可能需要额外的工作来确保提供静态压缩文件:
- 有关 IIS
web.config
压缩配置,请参阅 IIS:Brotli 和 Gzip 压缩 部分。 - 如果在不支持静态压缩文件内容协商的静态托管解决方案上进行托管,请考虑配置应用以提取和解码 Brotli 压缩文件:
从 google/brotli
GitHub 存储库中获取 JavaScript Brotli 解码器。 缩小的解码器文件被命名为 decode.min.js
,并且位于存储库的 js
文件夹中。
注释
如果 decode.js
脚本的缩小版本 (decode.min.js
) 失败,请尝试使用缩小版本 (decode.js
)。
更新应用以使用解码器。
在 wwwroot/index.html
文件中,在 autostart
的 false
标记上将 Blazor 设置为 <script>
:
<script src="_framework/blazor.webassembly.js" autostart="false"></script>
在 Blazor 的 <script>
标记之后和 </body>
结束标记之前,添加以下 JavaScript 代码 <script>
块。 以下函数使用 fetch
调用 cache: 'no-cache'
来更新浏览器的缓存。
Blazor Web App:
<script type="module">
import { BrotliDecode } from './decode.min.js';
Blazor.start({
webAssembly: {
loadBootResource: function (type, name, defaultUri, integrity) {
if (type !== 'dotnetjs' && ___location.hostname !== 'localhost' && type !== 'configuration' && type !== 'manifest') {
return (async function () {
const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
if (!response.ok) {
throw new Error(response.statusText);
}
const originalResponseBuffer = await response.arrayBuffer();
const originalResponseArray = new Int8Array(originalResponseBuffer);
const decompressedResponseArray = BrotliDecode(originalResponseArray);
const contentType = type ===
'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
return new Response(decompressedResponseArray,
{ headers: { 'content-type': contentType } });
})();
}
}
}
});
</script>
独立 Blazor WebAssembly:
<script type="module">
import { BrotliDecode } from './decode.min.js';
Blazor.start({
loadBootResource: function (type, name, defaultUri, integrity) {
if (type !== 'dotnetjs' && ___location.hostname !== 'localhost' && type !== 'configuration') {
return (async function () {
const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
if (!response.ok) {
throw new Error(response.statusText);
}
const originalResponseBuffer = await response.arrayBuffer();
const originalResponseArray = new Int8Array(originalResponseBuffer);
const decompressedResponseArray = BrotliDecode(originalResponseArray);
const contentType = type ===
'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
return new Response(decompressedResponseArray,
{ headers: { 'content-type': contentType } });
})();
}
}
});
</script>
有关加载启动资源的详细信息,请参阅 ASP.NET Core Blazor 启动。
若要禁用压缩,请将 CompressionEnabled
MSBuild 属性添加到应用的项目文件,并将值设置为 false
:
<PropertyGroup>
<CompressionEnabled>false</CompressionEnabled>
</PropertyGroup>
可在命令行界面中使用以下语法将 CompressionEnabled
属性传递给 dotnet publish
命令:
dotnet publish -p:CompressionEnabled=false
若要禁用压缩,请将 BlazorEnableCompression
MSBuild 属性添加到应用的项目文件,并将值设置为 false
:
<PropertyGroup>
<BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>
可在命令行界面中使用以下语法将 BlazorEnableCompression
属性传递给 dotnet publish
命令:
dotnet publish -p:BlazorEnableCompression=false
重写 URL,以实现正确路由
在 Blazor WebAssembly 应用中路由对页组件的请求不如在 Blazor Server 应用中路由请求直接。 假设有一个具有两个组件的 Blazor WebAssembly 应用:
-
Main.razor
:在应用的根目录处加载,并包含指向About
组件 (href="About"
) 的链接。 -
About.razor
:About
组件。
使用浏览器的地址栏(例如,https://www.contoso.com/
)请求应用的默认文档:
- 浏览器发出请求。
- 返回默认页,通常为
index.html
。 -
index.html
启动应用。 -
Router 组件进行加载,然后呈现 Razor
Main
组件。
在 Main 页中,选择指向 About
组件的链接适用于客户端,因为 Blazor 路由器阻止浏览器在 Internet 上发出请求,针对 www.contoso.com
转到 About
,并为呈现的 About
组件本身提供服务。 针对 Blazor WebAssembly 应用中的内部终结点的所有请求,工作原理都相同:这些请求不会触发对 Internet 上的服务器托管资源的基于浏览器的请求。 路由器将在内部处理请求。
如果针对 www.contoso.com/About
使用浏览器的地址栏发出请求,则请求会失败。 应用的 Internet 主机上不存在此类资源,所以返回的是“404 - 找不到”响应。
由于浏览器针对客户端页面请求基于 Internet 的主机,因此 Web 服务器和托管服务必须将对服务器上非物理方式资源的所有请求重写为 index.html
页。 如果返回 index.html
,应用的 Blazor 路由器将接管工作并使用正确的资源响应。
部署到 IIS 服务器时,可以将 URL 重写模块与应用的已发布 web.config
文件一起使用。 有关详细信息,请参阅使用 IIS 托管和部署 ASP.NET CoreBlazor WebAssembly。
使用 ASP.NET Core 进行托管部署
托管部署通过在 Web 服务器上运行的 ASP.NET Core 应用为浏览器提供 Blazor WebAssembly 应用。
客户端 Blazor WebAssembly 应用与服务器应用的其他任何静态 Web 资产一起发布到服务器应用的 /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot
文件夹。 这两个应用一起部署。 需要能够托管 ASP.NET Core 应用的 Web 服务器。 对于托管部署,Visual Studio 会在选择 Blazor WebAssembly 选项(使用 命令时为 blazorwasm
)的情况下,包含 dotnet new
应用项目模板(使用 Hosted
命令时为 -ho|--hosted
模板)。
如需了解更多信息,请参阅以下文章:
- ASP.NET Core 应用托管和部署:托管和部署 ASP.NET Core
- Azure 应用服务部署:通过 Visual Studio 将 ASP.NET Core 应用发布到 Azure
- Blazor 项目模板:ASP.NET Core Blazor 项目结构
针对特定平台的依赖于框架的可执行文件的托管部署
若要将托管的 Blazor WebAssembly 应用部署为针对特定平台的依赖于框架的可执行文件(非自包含),请根据所使用的工具利用以下指南。
Visual Studio
为生成的发布配置文件 () 配置了.pubxml
部署。 确认 Server 项目的发布配置文件包含设置为 <SelfContained>
的 false
MSBuild 属性。
在 .pubxml
项目的 Server 文件夹中的 Properties
发布配置文件中:
<SelfContained>false</SelfContained>
使用“发布”UI 的“设置”区域中的“目标运行时”设置来设置运行时标识符 (RID),这会生成发布配置文件中的 MSBuild 属性:
<RuntimeIdentifier>{RID}</RuntimeIdentifier>
在上述配置中,{RID}
占位符是运行时标识符 (RID)。
在“发布”配置中发布 Server 项目。
注释
通过将 /p:PublishProfile={PROFILE}
传递给 dotnet publish
命令(其中 {PROFILE}
占位符是配置文件),可以使用 .NET CLI 发布具有发布配置文件设置的应用。 有关详细信息,请参阅用于 ASP.NET Core 应用部署的 Visual Studio 发布配置文件 (.pubxml) 一文中的“发布配置文件”和“文件夹发布示例”部分。 如果在 dotnet publish
命令中而不是在发布配置文件中传递 RID,请将 MSBuild 属性 (/p:RuntimeIdentifier
) 与命令(而非 -r|--runtime
选项)一起使用。
.NET 命令行界面 (CLI)
通过将 MSBuild 属性置于 <SelfContained>
项目的项目文件中的 <PropertyGroup>
中并将其设置为 Server,来配置false
部署:
<SelfContained>false</SelfContained>
重要
SelfContained
属性必须置于 Server 项目的项目文件中。 无法使用 dotnet publish
选项或 MSBuild 属性 通过 --no-self-contained
正确设置该属性。
使用以下任一方法设置运行时标识符 (RID):
选项 1:在
<PropertyGroup>
项目的项目文件中的 Server 中设置 RID:<RuntimeIdentifier>{RID}</RuntimeIdentifier>
在上述配置中,
{RID}
占位符是运行时标识符 (RID)。在 Server 项目的“发布”配置中发布应用:
dotnet publish -c Release
选项 2:将
dotnet publish
命令中的 RID 作为 MSBuild 属性 (/p:RuntimeIdentifier
) 传递,而不是使用-r|--runtime
选项:dotnet publish -c Release /p:RuntimeIdentifier={RID}
在上述命令中,
{RID}
占位符是运行时标识符 (RID)。
如需了解更多信息,请参阅以下文章:
独立部署
独立部署将 应用作为客户端直接请求的一组静态文件提供。 任何静态文件服务器均可提供 Blazor 应用。
独立部署资产将发布到 /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot
或 bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish
文件夹中,其中 {TARGET FRAMEWORK}
占位符是目标框架。
Azure 应用服务
Blazor WebAssembly 应用可以部署到 Windows 上的 Azure 应用服务,该服务在 IIS 上托管应用。
目前不支持将独立的 Blazor WebAssembly 应用部署到适用于 Linux 的 Azure 应用服务。 我们建议使用 Blazor WebAssembly 托管独立的 应用,它支持这种情况。
包含 Docker 的独立产品
独立的 Blazor WebAssembly 应用作为一组静态文件发布,供静态文件服务器托管。
若要在 Docker 中托管应用,请执行以下操作:
- 选择支持 Web 服务器(例如 Nginx 或 Apache)的 Docker 容器。
- 将
publish
文件夹资产复制到 Web 服务器中定义的用于提供静态文件的位置文件夹。 - 根据需要应用其他配置,为 Blazor WebAssembly 应用提供服务。
有关配置指南,请参阅以下资源:
主机配置值
在开发环境中,Blazor WebAssembly 应用可以在运行时接受以下主机配置值作为命令行参数。
内容根
--contentroot
参数设置包含应用内容文件的目录的绝对路径(内容根目录)。 在下面的示例中,/content-root-path
是应用的内容根路径。
以本地方式在命令提示符下运行应用时传递该参数。 在应用的目录中,执行以下操作:
dotnet watch --contentroot=/content-root-path
在 IIS Express 配置文件中,向应用的
launchSettings.json
文件添加条目。 如果使用 Visual Studio 调试器并在命令提示符下运行dotnet watch
(或dotnet run
)来运行应用,则使用此设置。"commandLineArgs": "--contentroot=/content-root-path"
在 Visual Studio 中,在“属性”“调试”>“应用程序参数”中指定参数 。 在 Visual Studio 属性页中设置参数可将参数添加到
launchSettings.json
文件。--contentroot=/content-root-path
基路径
--pathbase
参数可设置使用非根相对 URL 路径本地运行的应用的应用基路径(将 <base>
标记 href
针对暂存和生产设置为 /
之外的路径)。 在下面的示例中,/relative-URL-path
是应用的基路径。 有关详细信息,请参阅 ASP.NET Core Blazor 应用基路径。
重要
不同于向 href
标记的 <base>
提供的路径,传递 /
参数值时不包括尾部反斜杠 (--pathbase
)。 如果在 <base>
标记中以 <base href="/CoolApp/">
形式(包括尾部反斜杠)提供应用基路径,则以 --pathbase=/CoolApp
形式(无尾部反斜杠)传递命令行参数值。
以本地方式在命令提示符下运行应用时传递该参数。 在应用的目录中,执行以下操作:
dotnet watch --pathbase=/relative-URL-path
在 IIS Express 配置文件中,向应用的
launchSettings.json
文件添加条目。 如果使用 Visual Studio 调试器并在命令提示符下运行dotnet watch
(或dotnet run
)来运行应用,则使用此设置。"commandLineArgs": "--pathbase=/relative-URL-path"
在 Visual Studio 中,在“属性”“调试”>“应用程序参数”中指定参数 。 在 Visual Studio 属性页中设置参数可将参数添加到
launchSettings.json
文件。--pathbase=/relative-URL-path
有关详细信息,请参阅 ASP.NET Core Blazor 应用基路径。
网址
--urls
参数设置 IP 地址或主机地址,其中包含侦听请求的端口和协议。
以本地方式在命令提示符下运行应用时传递该参数。 在应用的目录中,执行以下操作:
dotnet watch --urls=http://127.0.0.1:0
在 IIS Express 配置文件中,向应用的
launchSettings.json
文件添加条目。 如果使用 Visual Studio 调试器并在命令提示符下运行dotnet watch
(或dotnet run
)来运行应用,则使用此设置。"commandLineArgs": "--urls=http://127.0.0.1:0"
在 Visual Studio 中,在“属性”“调试”>“应用程序参数”中指定参数 。 在 Visual Studio 属性页中设置参数可将参数添加到
launchSettings.json
文件。--urls=http://127.0.0.1:0
配置裁边器
Blazor 对每个发布版本执行中间语言 (IL) 剪裁,以从输出程序集中删除不必要的 IL。 有关详细信息,请参阅配置适用于 ASP.NET Core Blazor 的裁边器。
配置链接器
Blazor 对每个发布版本执行中间语言 (IL) 链接,以从输出程序集中删除不必要的 IL。 有关详细信息,请参阅为 ASP.NET Core Blazor 配置链接器。
更改 DLL 文件的文件扩展名
本部分适用于 .NET 5 到 .NET 7。 在 .NET 8 或更高版本中,.NET 程序集使用 Webcil 文件格式部署为 WebAssembly 文件(.wasm
)。
如果防火墙、防病毒程序或网络安全设备阻止了应用的动态链接库 (DLL) 文件 (.dll
) 的传输,你可以按照本部分中的指导,更改应用的已发布 DLL 文件的文件扩展名。
更改应用的 DLL 文件的文件扩展名可能无法解决问题,因为许多安全系统会扫描应用文件的内容,而不仅仅是检查文件扩展名。
若要在阻止下载和执行 DLL 文件的环境中使用更可靠的方法,请采用以下方法之一:
- 使用 .NET 8 或更高版本,它使用 Webcil 文件格式将 .NET 程序集打包为 WebAssembly 文件(
.wasm
)。 有关详细信息,请参阅本文的 .NET 8 或更高版本中的 .NET 程序集的 Webcil 打包格式 部分。 - 在 .NET 6 或更高版本中,使用 自定义部署布局。
有第三方的方法来处理这个问题。 有关详细信息,请参阅 Awesome Blazor 中的资源。
发布应用后,使用 shell 脚本或 DevOps 生成管道将 .dll
文件重命名,以在应用的已发布输出的目录中使用其他文件扩展名。
在以下示例中:
- PowerShell (PS) 用于更新文件扩展名。
-
.dll
文件将重命名,以使用命令行中的.bin
文件扩展名。 - 已发布的Blazor启动清单中列出的文件,其文件扩展名为
.dll
,将被更新为.bin
文件扩展名。 - 如果服务辅助角色资产也正在使用中,PowerShell 命令会将
.dll
文件中列出的service-worker-assets.js
文件更新为.bin
文件扩展名。
若要使用不同于 .bin
的文件扩展名,请在以下命令将 .bin
替换为所需的文件扩展名。
在以下命令中,{PATH}
占位符是文件夹中已发布_framework
文件夹publish
的路径。
重命名文件夹中的文件扩展名:
dir {PATH} | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
重命名文件中的 blazor.boot.json
文件扩展名:
((Get-Content {PATH}\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\blazor.boot.json
如果服务辅助角色资产也正在使用中,因为该应用是 渐进式 Web 应用(PWA)::
((Get-Content {PATH}\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\service-worker-assets.js
在前面的命令中,{PATH}
占位符是已发布的 service-worker-assets.js
文件的路径。
若要解决压缩 blazor.boot.json
文件的问题,请采用以下任一方法:
- 重新压缩更新
blazor.boot.json
的文件,生成新blazor.boot.json.gz
文件和blazor.boot.json.br
文件。 (推荐) - 删除压缩的
blazor.boot.json.gz
和blazor.boot.json.br
文件。 (使用此方法禁用压缩。
对于 渐进式 Web 应用(PWA)的压缩 service-worker-assets.js
文件,请采用以下任一方法:
- 重新压缩更新
service-worker-assets.js
的文件,生成新service-worker-assets.js.br
文件和service-worker-assets.js.gz
文件。 (推荐) - 删除压缩的
service-worker-assets.js.gz
和service-worker-assets.js.br
文件。 (使用此方法禁用压缩。
若要在 .NET 6/7 中自动执行 Windows 上的扩展更改,以下方法使用放置在项目的根目录下的 PowerShell 脚本。 以下脚本会禁用压缩功能,如果应用是渐进式 Web 应用(PWA),希望重新压缩 blazor.boot.json
文件和 service-worker-assets.js
文件时,可在此基础上进行进一步修改。 当脚本执行时,文件夹的路径publish
会传递给脚本。
ChangeDLLExtensions.ps1:
:
param([string]$filepath)
dir $filepath\wwwroot\_framework | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\wwwroot\_framework\blazor.boot.json.gz
Remove-Item $filepath\wwwroot\_framework\blazor.boot.json.br
如果服务工作线程资源也在使用,因为该应用是 渐进式 Web 应用(PWA),请运行以下命令:
((Get-Content $filepath\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\wwwroot\service-worker-assets.js
Remove-Item $filepath\wwwroot\service-worker-assets.js.gz
Remove-Item $filepath\wwwroot\service-worker-assets.js.br
在项目文件中,在为 Release
配置发布应用后执行脚本:
<Target Name="ChangeDLLFileExtensions" AfterTargets="AfterPublish" Condition="'$(Configuration)'=='Release'">
<Exec Command="powershell.exe -command "& {.\ChangeDLLExtensions.ps1 '$(SolutionDir)'}"" />
</Target>
发布应用后,手动重新压缩 blazor.boot.json
, service-worker-assets.js
如果使用,则重新启用压缩。
注释
在重命名和延迟加载相同的程序集时,请参阅在 ASP.NET Core Blazor WebAssembly 中延迟加载程序集中的指南。
通常,应用的服务器需要静态资产配置才能提供具有更新扩展名的文件。 对于由 IIS 托管的应用,请在自定义 <mimeMap>
文件的静态内容部分 (<staticContent>
) 为新文件扩展名添加 MIME 映射条目 (web.config
)。 以下示例假定文件扩展名从 .dll
更改为 .bin
:
<staticContent>
...
<mimeMap fileExtension=".bin" mimeType="application/octet-stream" />
...
</staticContent>
如果正在进行压缩,请包含压缩文件的更新:
<mimeMap fileExtension=".bin.br" mimeType="application/octet-stream" />
<mimeMap fileExtension=".bin.gz" mimeType="application/octet-stream" />
删除 .dll
文件扩展名的条目:
- <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.br" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.gz" mimeType="application/octet-stream" />
有关自定义web.config
文件的详细信息,请参阅自定义web.config
部分的用法。
之前的部署损坏
通常在部署时:
- 只替换已更改的文件,这通常会加快部署速度。
- 不属于新部署的现有文件将保留在原位,供新部署使用。
在极少数情况下,之前部署中的延迟文件可能会损坏新部署。 完全删除现有部署(或在部署之前本地发布的应用)可能会解决部署损坏的问题。 通常,删除现有部署一次就足以解决问题,包括 DevOps 生成和部署管道。
如果确定在使用 DevOps 生成和部署管道时始终需要清除以前的部署,则可临时向生成管道添加一个步骤,来删除每个新部署的先前部署,直到对损坏的确切原因进行故障排除为止。