c# ASP.NET Core 的 IHostApplicationLifetime 和应用生命周期

ASP.NET Core 3.0+ 必须使用 IHostApplicationLifetime，因 IApplicationLifetime 已被移除；它适用于所有 Generic Host 场景，其 ApplicationStarted、Stopping、Stopped 三阶段有明确触发时机和资源清理约束。

什么时候该用 `IHostApplicationLifetime` 而不是 `IApplicationLifetime`

ASP.NET Core 3.0+ 已彻底移除 IApplicationLifetime，所有新项目必须用 IHostApplicationLifetime。如果你在升级旧项目时发现 IApplicationLifetime 注入失败或类型找不到，不是配置问题，而是它已被废弃——直接换为 IHostApplicationLifetime 即可。

这个接口由 HostBuilder 创建的 IHost 提供，适用于所有基于 Generic Host 的场景（Web、Worker Service、Console Host），不局限于 Web 应用。

IHostApplicationLifetime.ApplicationStarted 在应用真正就绪、中间件链已构建完成、监听器已启动后触发（此时 HTTP 请求可被接收）
IHostApplicationLifetime.ApplicationStopping 在收到终止信号（如 Ctrl+C、dotnet stop、K8s SIGTERM）后立即触发，但仍在处理已有请求
IHostApplicationLifetime.ApplicationStopped 在所有 ApplicationStopping 回调执行完毕、所有 IAsyncDisposable 资源释放完成后才触发

`ApplicationStopping` 里能安全做哪些事？不能做哪些事？

这是最容易出错的阶段：你以为还有足够时间清理，其实没有。

✅ 可以：取消长期运行的 CancellationTokenSource、关闭自定义后台任务、记录日志、调用 await _httpClient.PostAsync(...)（但必须设超时）
❌ 禁止：阻塞等待未完成的 I/O（如无超时的 Task.Wait()）、调用未设超时的同步网络请求、写入未缓冲的文件流（可能卡住）、依赖其他正在销毁的 Scoped 服务（它们可能已 Disposed）
⚠️ 注意：ApplicationStopping 的 CancellationToken 会在超时（默认 5 秒）后强制触发 ApplicationStopped，不会等你手动完成

public class GracefulShutdownService : IHostedService
{
    private readonly IHostApplicationLifetime _lifetime;
    private readonly ILogger _logger;

    public GracefulShutdownService(IHostApplicationLifetime lifetime, ILogger logger)
    {
        _lifetime = lifetime;
        _logger = logger;
    }

    public Task StartAsync(CancellationToken cancellationToken)
    {
        _lifetime.ApplicationStopping.Register(OnStopping);
        return Task.CompletedTask;
    }

    private void OnStopping()
    {
        _logger.LogInformation("Application is stopping. Initiating graceful shutdown...");
        // ✅ 正确：用独立 token 控制超时，避免拖垮整个生命周期
        using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(3));
        try
        {
            _cleanupTask?.Wait(cts.Token); // 假设 cleanupTask 是一个可等待的清理任务
        }
        catch (OperationCanceledException)
        {
            _logger.LogWarning("Cleanup timed out.");
        }
    }

    public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
}

为什么在 `ApplicationStarted` 里获取 `IServiceScope` 很危险？

因为此时 DI 容器虽已构建完成，但 Scoped 生命周期的服务尚未被任何请求激活，IServiceScope 的创建和释放机制还未进入常规轨道。强行在这里解析 Scoped 服务，可能导致：

服务实例被意外提升为 Singleton（尤其在非 Web 主机中）
数据库上下文（DbContext）提前初始化并持有连接，而后续请求可能复用或冲突
某些依赖 HttpContext 的服务（如 IUrlHelper）抛出 InvalidOperationException: No service for type 'Microsoft.AspNetCore.Http.HttpContext' has been registered.

正确做法是：只在 ApplicationStarted 中触发「无依赖」的初始化逻辑（如预热缓存、加载配置快照），或改用 IHostedService.StartAsync —— 它在相同时机执行，但明确支持依赖注入和作用域管理。

Linux 容器环境下 `ApplicationStopping` 不触发的常见原因

Kubernetes 或 Docker 默认发送的是 SIGTERM，但 .NET 进程若未正确注册信号处理器，或被包装脚本拦截，会导致 ApplicationStopping 完全不执行。

确认容器入口命令是 dotnet YourApp.dll，而非 sh -c "dotnet..." 等间接调用（会丢失信号传递）
检查是否启用了 DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 —— 极少数情况下会影响信号注册（罕见，但值得排查）
Dockerfile 中添加 STOPSIGNAL SIGTERM，并确保 docker stop 使用默认超时（10 秒），给 ApplicationStopping 留出时间

在 Program.cs 开头加日志验证信号捕获：

Console.CancelKeyPress += (s, e) =>
{
    Console.WriteLine("CancelKeyPress received");
    e.Cancel = true; // 防止进程立即退出，让 Host 自己处理
};

最隐蔽的问题是：你在 ApplicationStopping 里 await 了一个没设超时的异步操作，而容器平台只等 10 秒就发 SIGKILL —— 此时回调看似“没执行”，其实是执行了一半就被强杀了。

# linux # docker # 处理器 # app # ai # microsoft # kubernetes # c# # 作用域 # .net # 为什么 # 中间件 # for # 接口 # Generic # console # 异步 # 数据库 # http # 你在 # 已被 # 适用于 # 回调 # 移除 # 的是 # 是一个 # 这是 # 在这里 # 什么时候

返回目录在线咨询

上一篇： ,想看一些成功的摄影作品，有什么网站可以推荐？
下一篇：智能拖拽建站系统：可视化设计+自助模板一键生成官网

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

全网整合营销服务商

c# ASP.NET Core 的 IHostApplicationLifetime 和应用生命周期

什么时候该用 IHostApplicationLifetime 而不是 IApplicationLifetime

ApplicationStopping 里能安全做哪些事？不能做哪些事？

为什么在 ApplicationStarted 里获取 IServiceScope 很危险？

Linux 容器环境下 ApplicationStopping 不触发的常见原因

您的项目需求

什么时候该用 `IHostApplicationLifetime` 而不是 `IApplicationLifetime`

`ApplicationStopping` 里能安全做哪些事？不能做哪些事？

为什么在 `ApplicationStarted` 里获取 `IServiceScope` 很危险？

Linux 容器环境下 `ApplicationStopping` 不触发的常见原因