1. 中间件管道：面试官最爱考的第一道"分水岭"题
1.1 中间件到底在解决什么问题：从餐厅后厨说起
很多候选人一上来就背"中间件是处理HTTP请求和响应的组件"，这句话没错，但等于没说。面试官真正想听到的是：你能不能用一句话讲清中间件存在的原因，以及它和传统ASP.NET的HttpModule、HttpHandler之间的本质差异。
我自己常用的类比是餐厅后厨。想象一条传菜流水线，每道菜从进门到上桌要经过"验菜→洗菜→切配→烹饪→装盘"，每个环节只干自己那件事，干完传给下一环。中间件就是这一个个工位，而next就是连接工位的传送带。ASP.NET Core把整个HTTP请求处理拆成了这条管道，每个中间件既能决定"要不要继续传下去"，也能在"菜原路返回"时做二次处理——这就是经典的"洋葱模型"。
记得有一次面试，对方问我"如果管道中间有个中间件抛了异常，后面的中间件还会执行吗"。这是个很容易答错的地方。答案是：不会继续向前，但异常会被外层已经执行过next之前的代码捕获——前提是外层中间件写了try/catch。这正好解释了为什么全局异常处理中间件必须注册在管道最外层。
1.2 Run、Use、Map三兄弟的边界与坑
这是最基础的考点，但也是最容易翻车的。先说我的结论：Run就是终端中间件，Use是可以接力也可以终止的通用入口，Map则是按路径分流。但实际面试时，光背定义没用，面试官更想听你踩过什么坑。
我自己写过的一个真实案例是：有一个中间件在app.Use()里做了await next()之后，又去读取了一次Response.Body想记录响应日志。结果发现读取出来是空字符串。原因在于响应体是流类型，读完必须把Position归零，否则next已经写完的内容已经被"消耗"掉了。更稳妥的做法是把Response.Body替换成MemoryStream，等所有中间件执行完再统一读取。
另一个高频追问是"Map和Use的混用顺序问题"。Map的本质其实是创建了管道的一个分支，分支内部的执行顺序是独立的。很多人以为Map之后写的中间件在分支上也生效，其实不会——分支内部只会执行Map的回调里注册的那些中间件。这个理解偏差，面试时特别容易被追问到"如果我把Map("/health")放在Use的异常处理中间件之后会怎样"——答案很简单：健康检查分支不会经过异常处理。
1.3 手写一个带依赖注入的商用级自定义中间件
如果面试环节让你现场写一个中间件，别只会写app.Use(async (context, next) => {...})那种内联的。能用"类 + 依赖注入"的方式组织，才是加分项。下面这个是我在生产环境用过的请求日志中间件，保留了核心逻辑：
public class RequestLoggingMiddleware { private readonly RequestDelegate _next; private readonly ILogger<RequestLoggingMiddleware> _logger; public RequestLoggingMiddleware(RequestDelegate next, ILogger<RequestLoggingMiddleware> logger) { _next = next; _logger = logger; } public async Task InvokeAsync(HttpContext context, IHostEnvironment env) { var sw = Stopwatch.StartNew(); var originalBody = context.Response.Body; await using var memoryStream = new MemoryStream(); context.Response.Body = memoryStream; try { await _next(context); memoryStream.Position = 0; var responseBody = await new StreamReader(memoryStream).ReadToEndAsync(); memoryStream.Position = 0; await memoryStream.CopyToAsync(originalBody); _logger.LogInformation( "请求 {Method} {Path} 完成，状态码 {StatusCode}，耗时 {Elapsed}ms，响应长度 {Length}", context.Request.Method, context.Request.Path, context.Response.StatusCode, sw.ElapsedMilliseconds, responseBody.Length); } finally { context.Response.Body = originalBody; } } }注意有两个关键细节：中间件构造器里只能注入单例服务（比如ILogger<T>），需要Scoped或Transient服务时，必须把服务通过InvokeAsync的参数注入，因为中间件本身是单例注册的，你没法在构造函数里拿DbContext。这个知识点几乎是我面试时必问的，答不上来非常掉分。另一个细节是替换Response.Body后必须在finally里还原，否则会污染后续请求。
注册方式也很简单，在Program.cs里加一行：
app.UseMiddleware<RequestLoggingMiddleware>();1.4 面试追问：短路中间件与管道复用的场景延伸
面试官通常会在这个环节追问一个场景："如果某接口的内网IP黑名单校验没通过，怎么让请求在王炸前停下来？"这就是中间件短路的典型场景。实现方式有两种：一种是直接在中间件里写return;而不调用next，另一种是调用context.Abort()——但Abort会直接断开连接，客户端收到的不是HTTP响应而是连接重置，非极端情况不建议用。
另一个延展是管道复用。比如写一个功能开关中间件，根据IConfiguration里的开关决定这组中间件是否启用。这个我见过很多面试者会懵，其实思路就是在Startup或Program.cs里把一组app.Use...()封装成一个扩展方法，按条件调用即可。这个点考察的不是代码量，而是你对管道可组合性的理解。
2. 依赖注入：生命周期三个Scope的底层账本
2.1 三种生命周期在真实请求中的分配逻辑
ASP.NET Core的依赖注入容器（内置的ServiceProvider）是面试必问的区，而"生命周期"是其中最有深度的部分。AddSingleton、AddScoped、AddTransient的区别大家都背得出来，但面试官更关心的是"在同一个请求内，同一个Scoped服务的实例是同一个吗"——答案在默认情况下是同一请求内相同，但这取决于你从哪里拿。
我遇到过一个真实场景：在中间件InvokeAsync里头通过context.RequestServices.GetService(typeof(MyScopedService))取服务，会拿到跟控制器里注入的是同一个实例。但如果你在后台任务（BackgroundService）里解析同一个Scoped服务，对不起，拿不到，因为后台任务不在HTTP请求的Scope内。这个差异背后是IServiceScope的概念——每个HTTP请求会创建自己的Scope，请求内所有Scoped服务都挂在同一个Scope下。
很多面试者只知道"Scoped是请求级的"，但不知道请求结束时容器会把Scope里的服务统一释放（调用IDisposable.Dispose或IAsyncDisposable.DisposeAsync）。如果你在这个服务里还持有第三方连接没释放，就会导致连接泄漏。
2.2 捕获依赖的灾难现场：为什么不能从Singleton拿Scoped
"从单例里注入作用域服务"是经典高压线，面试时几乎百分百追问。原因很清晰：单例服务的生命周期是整个应用级，如果它注入了一个请求级（Scoped）的服务，那这个Scoped服务实际上被"升级"成了单例，然后这个服务以及它引用的所有资源（比如DbContext、数据库连接）都变成了进程级共享，在高并发下引发各种诡异问题——最常见的包括DbContext并发冲突和数据库连接耗尽。
我见过一个典型的线上事故：有个Singleton缓存服务为了做"缓存失效时回源数据库"，直接注入了一个Scoped的仓储服务。测试环境并发低，没暴露；上线后接口一压测，数据库连接池直接打满。排查了半天，最后用dotnet-counters看到连接数居高不下，才定位到这个"捕获依赖"的问题。
正确解法是：在Singleton服务里注入IServiceScopeFactory，用它在方法内部自行创建Scope去解析一次性服务：
public class CacheService : ICacheService { private readonly IServiceScopeFactory _scopeFactory; public CacheService(IServiceScopeFactory scopeFactory) { _scopeFactory = scopeFactory; } public async Task<Product> GetProductAsync(int id) { using var scope = _scopeFactory.CreateScope(); var repo = scope.ServiceProvider.GetRequiredService<IProductRepository>(); return await repo.GetByIdAsync(id); } }谈到这，面试官还很爱问"那如果我非要往单例里注入Scoped框架会怎么处理"。如果你没开启ValidateScopes校验，默认生产环境是不报错的，问题会静默存在。开发环境下由于ValidateScopes=true会直接抛InvalidOperationException错误提示。很多人第一次见到这个异常会一头雾水，其实就是这个机制在保护你。
2.3 服务注册顺序和TryAdd的幂等思想
还有一个经常被忽略的小考点：services.AddSingleton<T>()注册了两次同类型服务时，最后一次会覆盖前一次，当然这只是默认行为。如果两个不同程序集都调用了AddSingleton且都指望自己生效，Bug就会很隐蔽。所以微软提供了TryAdd系列的扩展方法——"不存在才添加，存在就跳过"。这个幂等思想在模块化设计里很重要，面试时可以主动提一句"我会用TryAdd避免重复注册覆盖"。
2.4 手动解析服务的几种姿势与Autofac替换
真遇到必须手动解析的场景，我有三个可选姿势：注入IServiceProvider、注入IServiceScopeFactory创建Scope再拿，或者写一个服务定位器（ServiceLocator）——但最后一种能不用就不用，因为它会隐藏依赖关系，代码可维护性很差。面试时提到ServiceLocator是反模式，本身就能体现你知道的边界在哪里。
如果面试官问"内置容器不够用怎么办，比如要注册带条件属性的AOP功能"，答案往往是"换成Autofac"。Autofac可以替代内置容器，核心步骤就三步：包换成Autofac.Extensions.DependencyInjection，Program.cs里指定Host.UseServiceProviderFactory(new AutofacServiceProviderFactory())，再配置ConfigureContainer来注册模块。我记得当时改造一个老项目时，最大的收益是能轻松做"基于Key的服务解析"和"属性注入"，这两种能力内置容器至今做不了。
3. IOptions三兄弟：配置系统的"同源不同命"
3.1 一个表格看清IOptions、IOptionsSnapshot、IOptionsMonitor
配置系统这块，面试官问的最多的就是IOptions家族。很多人能背"Snapshot支持热更新、Monitor支持热更新且可以被监听"——但说不清该怎么选。我整理一张表，你直接拿去用：
| 接口 | 生命周期 | 读取时机 | 是否支持配置热更新 | 典型场景 |
|---|---|---|---|---|
IOptions<T> | 单例 | 首次解析时 | 不支持 | 启动后基本不变的全局设置 |
IOptionsSnapshot<T> | 作用域 | 每次解析时 | 支持（每请求重新读取） | 每请求可能不同的配置，或依赖请求头的动态配置 |
IOptionsMonitor<T> | 单例 | 首次解析 + 可监听变更 | 支持（监听变更回调） | 需要缓存又需要感知配置变化的服务 |
这里有个好玩的细节：IOptionsSnapshot<T>虽然在文档里说"每请求读取一次"，但它的热更新能力其实依赖appsettings.json的reloadOnChange: true默认开启。如果你在AddJsonFile时手贱把reloadOnChange改成了false，那么Snapshot也不会更新。面试如果问到这儿，你可以补一句"我在实际项目中，会用IOptionsSnapshot接受配置热更新，但不会用它做秒级频繁变更的配置源，因为它毕竟还是要重新绑定，成本不是零"。
3.2 ChangeToken：热更新机制背后的鱼线理论
IOptionsMonitor之所以能感知配置变化，功劳全在ChangeToken。它的机制跟你钓鱼时用鱼线连接浮漂和鱼钩类似——Configuration登记了一批"当文件被修改时要通知谁"的订阅者，文件系统FileSystemWatcher发现变化后，触发ChangeToken，Monitor再重新读取配置并通过OnChange回调通知订阅方。
实际使用OnChange时有个容易踩的坑：回调是在后台线程上执行的，不要在回调里直接操作UI或请求级上下文（比如HttpContext），因为此时作用域已经不存在了。正确姿势是把变更事件写进日志，或者通过消息队列广播给相关服务去更新自己的缓存。如果有多个服务实例（负载均衡/多节点部署），OnChange只会在当前进程触发——这引出一个关键提示：多节点场景下的配置热更新，不能只靠ChangeToken，必须借助配置中心或消息订阅。
3.3 配置绑定与验证：让错误配置在启动时就爆雷
配置验证是很多团队会跳过的保命环节。IOptions默认不做任何验证，配置少了个必填项，服务跑起来才会炸。我推荐的做法是使用IValidateOptions<T>或在ConfigureOptions里指定ValidateDataAnnotations：
services.AddOptions<DatabaseOptions>() .Bind(configuration.GetSection("Database")) .ValidateDataAnnotations() .Validate(options => { if (options.MaxConnectionCount <= 0) throw new InvalidOperationException("MaxConnectionCount 必须大于0"); return true; }) .ValidateOnStart();ValidateOnStart()是我强烈推荐加的一行——它会让验证在应用启动时就强制执行，而不是等到第一次解析配置时才校验。我曾经在一个支付网关项目里因为漏配置了CallbackUrl，服务启动一切正常，直到有用户实际支付了才发现回调地址是空的，最终还是靠ValidateOnStart在部署阶段就拦截掉了这类问题。
4. 认证授权：JWT之外，你还需要拿得出手的策略式权限设计
4.1 认证与授权：先验明身份，再决定给不给进
面试环节谈到安全，最怕候选人把认证和授权混成一锅粥。认证（Authentication）回答的是"你谁啊"，授权（Authorization）回答的是"你能干啥"。在ASP.NET Core的管道里对应两个中间件UseAuthentication和UseAuthorization，且顺序必须是认证在前、授权在后——这就像考场的门卫流程，先查准考证确认是你本人，再查座位号安排你在哪间教室坐。
一个我自己见过的错误是：有人在Program.cs里先写了app.UseAuthorization()又写app.UseAuthentication()，结果所有需要权限的接口全部返回401，实际上是因为认证还没跑，HttpContext.User还是空的。
4.2 基于JWT的令牌认证完整流程复盘
JWT是当前最主流的接口认证方案。面试时如果可以，把整个流程像说故事一样完整串起来：客户端登录成功后，服务端用密钥对用户ID、过期时间、角色等Claim做签名，生成Token返回；客户端之后在Header里带上Authorization: Bearer <token>；服务端在UseAuthentication阶段校验签名、检查过期时间，把Token里面的Claim还原成ClaimsPrincipal塞进HttpContext.User。
我用AddJwtBearer做基础配置的时候，最容易被忽略的是TokenValidationParameters的三个参数：
new TokenValidationParameters { ValidateIssuer = true, ValidIssuer = "yourapp", ValidateAudience = true, ValidAudience = "yourclient", ValidateLifetime = true, ClockSkew = TimeSpan.FromMinutes(1), ValidateIssuerSigningKey = true, IssuerSigningKey = new SymmetricSecurityKey(secretBytes) };ClockSkew这个坑值得拿出来讲：默认值是5分钟，意味着Token过期后5分钟内还能通过校验。这在安全要求高的系统里是不能接受的。我有一次排查一个"退出了还能访问接口几分钟"的问题，最后就找到了这里。另一个细节是IssuerSigningKey如果用Encoding.UTF8.GetBytes每次现算也行，但密钥长度低于32字节时SymmetricSecurityKey会直接抛异常。
4.3 Policy-Based授权与自定义AuthorizationHandler的实战地位
基于角色的[Authorize(Roles = "Admin")]能应付大多数简单场景，但真遇到"管理员或资源的所有者才能编辑"这类动态条件，就需要Policy加持。合理做法是先定义Policy，再把策略与Handler绑定：
services.AddAuthorization(options => { options.AddPolicy("CanEditResource", policy => { policy.RequireAuthenticatedUser(); policy.AddRequirements(new ResourceOwnerRequirement()); }); }); public class ResourceOwnerRequirement : IAuthorizationRequirement { } public class ResourceOwnerHandler : AuthorizationHandler<ResourceOwnerRequirement> { protected override Task HandleRequirementAsync( AuthorizationHandlerContext context, ResourceOwnerRequirement requirement) { var resourceId = context.Resource?.ToString(); var userId = context.User.FindFirstValue(ClaimTypes.NameIdentifier); if (resourceId != null && userId == resourceId.Split(':')[0]) { context.Succeed(requirement); } return Task.CompletedTask; } }Handler默认注册为单例，所以如果你想在Handler里用DbContext，必须像中间件那样注入IServiceScopeFactory来创建作用域——这个陷阱跟第2章的捕获依赖如出一辙。另外注意AuthorizationHandlerContext.Resource是从哪传进去的：[Authorize]标注的Controller或页面就是Resource，如果你想拿更细粒度的对象，得用别的方式传，比如IAuthorizationService手动AuthorizeAsync时才可以把业务对象作为resource参数传进去。
4.4 401和403：看似简单却容易被绕过的权限边界
还真有面试者答不清401和403的差别。401等于"你没登录或登录已失效"，403等于"你登了但没权限"。JWT场景中401常见于没有Token或Token过期；403常见于RequireClaim/Policy没通过。有个细节容易被忽略：如果UseAuthorization之后又不小心注册了一个会清空User身份的中间件，调用方带啥Token都可能被当成匿名用户返回401——这种问题查起来特别费劲，最早的排查方向是抓HttpContext.User是否正常。
5. 性能与诊断：面试中让印象分飙升的实战经验
5.1 响应压缩、内存缓存与分布式缓存的选型逻辑
性能优化是面试后半场的高频区。我通常会给候选人一个判断框架：先看瓶颈在CPU还是IO、在数据库还是网络，再决定优化方案。ResponseCompression中间件可以把大数据量响应的传输体积缩小60%-80%，但它默认情况下不压缩application/json以外的类型，且对已压缩的资源（图片、视频）无效。注册方式很简单：
services.AddResponseCompression(options => { options.EnableForHttps = true; options.Providers.Add<BrotliCompressionProvider>(); options.Providers.Add<GzipCompressionProvider>(); }); app.UseResponseCompression();缓存方面，IMemoryCache管进程内、IDistributedCache管跨进程分布式。现状是很多人把IMemoryCache当成万能药，但一旦应用多实例部署，进程内缓存的一致性就成了大问题——各实例缓存各自的副本，互相不知道对方有没有更新。分布式缓存的典型选型有StackExchange.Redis、SqlServerCache，其中Redis延迟最低、功能最全面。我的通常做法是"两级缓存"：热数据先查内存，Miss再查分布式缓存，再Miss才查库，用分布式缓存保证最终一致性，用内存缓存扛住瞬时热点压力。
这个方案面试时特别加分，因为它体现的不是"会用某个缓存组件"，而是"懂得取舍与一致性权衡"。
5.2 高频场景下的内存分配优化误区
我说几个真实可操作的优化手段，但同时也提醒一句"性能优化必须基于度量，不能靠猜"：
| 优化点 | 做法 | 收益 |
|---|---|---|
| 字符串拼接 | 高频循环内用StringBuilder或string.Create | 减少中间堆分配 |
| 异步避免阻塞 | 全程async/await，不要.Result/.Wait() | 避免线程池饥饿 |
| EF Core查询 | .AsNoTracking()、只投影需要的列 | 大幅降低跟踪开销和内存占用 |
| 序列化 | System.Text.Json默认UTF-8，比Newtonsoft更快 | 高吞吐接口有肉眼可见改善 |
| 池化 | 用ArrayPool<T>处理大数组临时缓冲 | 减少GC压力 |
打个比方，大数组的反复分配就像你每天倒掉一整杯水再接一杯，虽然没浪费多少，但水压稍大时垃圾回收（GC）就会开始频繁"清场"。ArrayPool是图书馆里的共享书桌，用完归还，别人还能用，省掉了大量清理成本。
5.3 从dotnet-counters到日志诊断：事故排查三板斧
面试如果聊到线上问题排查，能把工具链娓娓道来是很加分的。我常按这个顺序来：
dotnet-counters：先看全局计数器的热力图，比如gc-heap-size、threadpool-thread-count、working-set，判断方向是内存陡增、线程饥饿还是GC频繁。dotnet-dump+dotnet-analyze：如果问题锁定在某次请求，抓内存快照分析有哪个对象占大头。dotnet-trace：CPU密集型问题，抓事件跟踪，看哪个方法占用CPU时间最长。
比如有一次接口突然变慢，我先用dotnet-counters发现threadpool-queue-length持续走高，方向定位到"线程池饥饿"，再用dotnet-trace抓到有个同步阻塞调用堵死了一批线程，真相是一个老同事在异步方法里写了.Result()。这种定位思路本身，比背任何工具参数都有说服力。
日志侧我推荐用Serilog做结构化日志，因为结构化日志可以让日志从"给人看"变成"给机器看"，后续串联OpenTelemetry或Application Insights做链路追踪时省很多事。有一点要注意：日志级别一定要留足够的运行时调整空间——如果上线后发现Debug日志把磁盘打爆，你会感谢当初封装了MinimumLevel的动态配置。
6. 我给候选人的一句真心话
面试这件事，说到底是"你懂不懂边界"的检验。中间件管道的洋葱结构、依赖注入的生命周期约束、IOptions三兄弟的适用边界、认证授权的先后顺序——每一个问题背后都对应着线上真实出过事的场景。与其死记八股文、背答案，不如像我一样在自己电脑上把Demo跑一遍，故意写几个"错误代码"看它在什么时候崩溃，这种肌肉记忆式的理解，远比背诵定义更能在面试现场撑住场面。
另外一个小建议：准备面试时，把你踩过的每个坑写成一段"问题描述+排查过程+最终解法"的三段式笔记。面试官问你"遇到过什么难题"时，你用自己的真实故事回答，比任何标准答案都更有说服力。我在带团队面试时，最青睐的就是表现出"知道为什么会出错、也知道怎么验证修复"的候选人。
