ASP.NET Core Startup类中services.Add与app.Use的区别及用法

二者分属应用启动的两个完全独立阶段，职责边界非常清晰：

• services.Add* 是服务注册操作，运行在ConfigureServices阶段
  这个阶段是应用启动的第一步，作用是把后续要用到的所有功能、组件、服务都注册到依赖注入(DI)容器里，相当于提前给应用备齐所有要用的“零件”。这个阶段的所有Add操作，都只是声明“我要用这个功能，帮我把它准备好”，不会涉及任何实际的HTTP请求处理，你可以在这里配置服务的生命周期（单例/请求作用域/瞬时）、配置参数、替换默认实现。
  你代码里的AddControllers、AddSwaggerGen、AddCors，还有自定义的AddApplicationServices、AddIdentityServices全属于这类操作——比如AddCors()只是把跨域需要的底层服务注册好，如果不在后续管道中调用UseCors()，跨域配置根本不会生效。
• app.Use* 是管道配置操作，运行在Configure阶段
  等ConfigureServices完成所有服务注册，应用就会进入这个阶段构建HTTP请求处理管道。你写的每一个Use*方法，都是往管道里插入一个中间件，所有发往应用的请求，都会严格按照你写Use方法的顺序依次经过这些中间件处理，生成响应之后，再按反向顺序经过中间件返回给客户端。
  打个简单的比方：Add是把工具买回家放到储物柜里，Use是把工具拿出来按使用顺序摆到流水线上，没有提前Add过的功能，直接调用Use会直接报错。

示例代码的逻辑说明与注意点 #

对应你贴的代码片段，几个关键逻辑和容易踩坑的点如下：

1. 构造函数注入的IConfiguration是框架提供的配置提供器，用来读取appsettings.json、环境变量、命令行参数等配置内容，你把它存为私有字段传给两个自定义Add扩展方法是很常规的写法。
2. ConfigureServices里的内容全是标准服务注册，没有逻辑问题：
   • AddControllers注册Web API控制器的核心依赖服务
   • AddSwaggerGen注册Swagger接口文档的生成服务
   • AddCors注册跨域功能的基础依赖服务
   • 两个自定义扩展方法一般是把业务服务注册、身份认证（比如JWT校验）相关的零散注册逻辑做了封装，和框架内置的Add方法没有本质区别
3. Configure里的管道配置有几个需要留意的细节：

   你把默认开发环境的异常页、Swagger中间件注释掉，换成自定义的ExceptionMiddleware是合理的，全局异常中间件必须放在管道最开头，才能捕获后面所有中间件执行时抛出的异常。

   • 中间件顺序直接决定功能是否正常，你现在写的顺序是：全局异常处理 → HTTPS重定向 → 路由匹配 → CORS跨域处理，其中CORS的位置是正确的——CORS必须放在UseRouting之后，授权、端点映射之前，放错位置跨域配置会直接失效。
   • 你当前写的CORS规则是允许任意来源、任意请求头、任意请求方法，同时允许携带凭证，仅适合本地开发调试使用，上线前必须替换成指定的允许来源域名，否则会存在跨域安全风险。
   • 你贴的代码片段没有写完，CORS配置后面通常还要补充UseAuthentication、UseAuthorization（如果项目用了身份认证、授权功能），最后加端点映射逻辑（.NET 5及之前版本写app.UseEndpoints(endpoints => endpoints.MapControllers())，.NET 6+可以直接写app.MapControllers()），少了这步请求根本不会路由到控制器里。

通用避坑提示 #

• 不要在ConfigureServices里尝试读取HTTP上下文、处理请求，这个阶段请求管道还没构建完成，根本不存在请求对象
• 不要在Configure阶段尝试注册新服务，这时候DI容器已经构建完毕，新增的服务不会被框架识别
• 中间件顺序不要随意调整，通用的正确管道顺序参考：
  全局异常处理 → HTTPS重定向 → 静态文件处理 → CORS → 路由 → 身份认证 → 授权 → 端点映射（控制器执行入口）

内容的提问来源于stack exchange，提问作者Mohammed Awad