.Net Core 3.1 IdentityServer4 FindByNameAsync 始终返回 null 问题

两段代码传入的查询值完全一致、直接EF查询能命中数据，但FindByNameAsync返回null，通常是以下几类实际环境/实现的问题，和你参考的源码逻辑没有直接矛盾：

• 你当前拿到的userStore实例根本不是EF Core 实现的官方UserStore<TUser>。如果你通过服务注册手动替换过IUserStore<TUser>的实现（比如为了适配IdentityServer4的扩展、自定义的用户加密逻辑），但没有正确复写FindByNameAsync的查询逻辑（比如错误匹配了UserName而非NormalizedUserName字段、拼接了多余的过滤条件），就会出现原生EF查询能命中、走自定义UserStore方法查不到的情况。你之前参考的main分支源码逻辑，是官方EF Core UserStore的实现，和你项目里实际运行的方法可能完全不是同一个代码。
• IdentityServer4 4.1.1配套的IdentityServer4.AspNetIdentity集成模块，在服务注册时会隐式替换部分Identity相关的服务实现，部分版本存在已知的查询逻辑缺陷，会导致FindByNameAsync查询时遗漏匹配条件，返回null。
• 两个查询链路用到的DbContext配置不一致。理论上同一个Scoped生命周期内的userStore.Context和UserStore内部使用的DbContext是同一个对象，但如果服务注册时存在生命周期不匹配（比如UserStore被注册成单例、DbContext被注册成Scope），就会导致UserStore内部初始化时拿到的DbContext模型配置，和你直接访问的Context配置存在差异：比如直接访问的Context没有加载实体的全局查询过滤器，而UserStore用的DbContext加载了租户隔离、软删除等全局过滤规则，查询时因为不满足过滤条件直接返回null。
• 你参考的源码版本和项目实际引用的Identity版本不匹配。你对照的是main分支的最新版源码，但.NET Core 3.1对应的ASP.NET Core Identity 3.1.x版本中，FindByNameAsync的实现并非完全是简单的NormalizedUserName匹配：部分3.1发布版本的实现会在查询时隐式拼接租户字段校验、是否支持外部登录用户等额外条件，如果你传入的用户记录不满足这些隐式条件，就会返回null。
• 字符串归一化的隐式差异。虽然两段代码看起来用的是同一个userManager.NormalizeName(model.Username)的返回值传参，但如果项目里注册了自定义的ILookupNormalizer实现，在不同的服务实例作用域下，同一个输入生成的归一化值可能存在大小写、全半角的差异，导致传入FindByNameAsync的参数值和数据库存储的NormalizedUserName不匹配。

排查技巧：在调用FindByNameAsync的位置开启EF Core日志输出，打印该方法实际生成的SQL语句，和自定义直接查询生成的SQL做逐行对比，可快速定位两者的Where条件差异。

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