ASP.NET Core 问答 01：宿主、管道、配置与依赖注入

结论： 它创建带有常用默认配置的 WebApplicationBuilder，并暴露配置、日志、服务和宿主设置入口

原因： 默认值整合了配置源、日志提供程序、Kestrel 与 Generic Host，减少重复启动代码

边界： 默认值不是不可更改的魔法，应用仍要显式注册业务服务和安全管道

最小示例： 在 builder.Services 注册服务，在 builder.Build 后配置中间件

结论： 宿主负责启动服务、运行应用并在停止时协调取消与释放

原因： IHostApplicationLifetime 和停止令牌让托管服务有机会完成有界清理

边界： 进程被强杀时不能保证清理完成，关键状态仍需持久化和幂等恢复

最小示例： BackgroundService 监听 stoppingToken 并及时退出

结论： Kestrel 是应用内 HTTP 服务器，反向代理通常处理公网入口、TLS、负载均衡和边缘策略

原因： 两者职责分层可以集中证书与入口治理，同时保留应用服务器的协议处理

边界： Kestrel 可以直接暴露公网，但必须自行承担证书、限流、补丁和网络防护

最小示例： 代理转发时正确配置 Forwarded Headers

结论： 请求按注册顺序进入、响应按相反顺序返回，短路还会阻止后续组件执行

原因： 异常处理、静态文件、路由、认证与授权都依赖前后关系

边界： 具体顺序按应用能力决定，不能机械复制一张固定清单

最小示例： 异常处理中间件应包住需要捕获的后续管道

结论： 中间件生成响应后不调用 next，请求就不会继续进入后续组件

原因： 静态文件、缓存命中和拒绝请求常利用短路减少工作

边界： 短路前必须完成必要的安全检查，不能让公开分支绕过授权

最小示例： 命中静态资源后直接返回

结论： 中间件实例通常在应用生命周期内复用，而 InvokeAsync 参数可按请求解析 scoped 服务

原因： 构造函数捕获 scoped 服务会把请求生命周期错误提升到长期实例

边界： IMiddleware 通过工厂激活时可使用不同生命周期模型，需按注册方式判断

最小示例： public Task InvokeAsync(HttpContext context, MyScopedService service)

结论： Use 可调用下一组件，Run 终止当前分支，Map 按路径创建独立分支

原因： 它们分别表达组合、终点和分支，影响后续中间件是否可达

边界： MapWhen 按任意谓词分支，分支条件必须避免意外绕过安全组件

最小示例： app.Map(“/health”, branch => branch.Run(…))

结论： 路由先匹配 Endpoint，随后授权等中间件读取元数据，最后执行端点

原因： 将匹配与执行分开后，中间件可基于端点元数据做决策

边界： 最小托管模型会自动加入部分路由行为，但显式顺序仍影响依赖 Endpoint 的组件

最小示例： 在匹配后、执行前调用授权中间件

结论： 按状态共享范围和依赖生命周期选择，而不是按创建速度选择

原因： Transient 每次解析新建，Scoped 通常每请求共享，Singleton 跨应用共享

边界： 线程安全、资源所有权和被依赖服务的生命周期必须同时考虑

最小示例： DbContext 通常 scoped，无状态线程安全缓存可 singleton

结论： 长生命周期对象会捕获短生命周期实例，造成跨请求共享和释放时机错误

原因： 容器的作用域验证会在开发期帮助发现 captive dependency

边界： 需要临时 scoped 工作时应创建显式作用域，且不能把作用域对象带出去

最小示例： 使用 IServiceScopeFactory.CreateScope

结论： 每轮工作创建并释放作用域，再从 scope.ServiceProvider 解析 scoped 服务

原因： Hosted Service 默认是 singleton，没有天然 HTTP 请求作用域

边界： 并行任务各自需要独立作用域，DbContext 也不能跨线程共享

最小示例： await using var scope = scopeFactory.CreateAsyncScope()

结论： 同一服务契约有多个命名实现时，可按 key 注册和解析

原因： 它比手写 switch 集中表达实现选择，并可用于端点参数注入

边界： key 不是安全边界，来自外部输入时仍需白名单验证

最小示例： AddKeyedScoped<IStore, SqlStore>(“sql”)

结论： IOptions 提供稳定值，Snapshot 每作用域重算，Monitor 可观察变更并适合 singleton

原因： 三者缓存与生命周期不同，影响热更新可见性

边界： 配置源必须支持重载，且变更后的对象仍需验证

最小示例： singleton 消费动态配置时使用 IOptionsMonitor

结论： 后添加的提供程序对相同键拥有更高优先级

原因： 这让命令行、环境变量等覆盖文件默认值

边界： 数组和复杂对象的合并行为需按绑定结果验证，不能假定所有层都深合并

最小示例： 环境变量覆盖 appsettings.json 的连接配置

结论： 跨平台通常用双下划线映射配置层级分隔符

原因： 部分 Shell 不便使用冒号，双下划线更可移植

边界： 变量名大小写和平台行为可能不同，部署清单要统一

最小示例： ConnectionStrings__Default

结论： 放入受控机密存储或部署平台的秘密机制，不提交到源码和普通配置文件

原因： 机密需要访问控制、轮换和审计，User Secrets 主要服务本地开发

边界： 环境变量也可能被进程或诊断工具读取，仍要控制主机权限

最小示例： 本地用 User Secrets，生产用云机密服务

结论： 消息模板保留字段结构，便于检索、聚合并避免不必要格式化

原因： 日志后端可按属性建立查询和指标

边界： 不要记录令牌、密码和完整个人数据，结构化不等于自动脱敏

最小示例： logger.LogInformation(“Order {OrderId}”, id)

结论： 响应停止令牌、停止接收新工作，并在超时内完成或持久化在途任务

原因： 宿主只提供协作式取消，业务代码必须传播令牌并设计可恢复点

边界： 关机超时后进程仍可能终止，不能依赖无限清理

最小示例： 保存消费位点后退出循环

结论： 绑定 Options 后使用验证并调用 ValidateOnStart

原因： 尽早失败比流量进入后才出现空值或格式错误更可诊断

边界： 外部依赖可用性不宜都变成永久启动阻塞，应区分配置错误和暂时故障

最小示例： AddOptions<T>().BindConfiguration(“X”).ValidateDataAnnotations().ValidateOnStart()

结论： 它提供当前请求作用域的 IServiceProvider，但常规业务依赖仍应优先构造或参数注入

原因： 服务定位隐藏依赖并降低可测试性，RequestServices 主要用于基础设施或动态场景

边界： 请求结束后不得保存其中解析出的 scoped 对象

最小示例： 端点过滤器按元数据动态解析专用服务