注入AppDbContext的仓储类如何自动筛选仅属于当前登录用户的数据？

结论先行 #

不建议在构造函数中实现过滤逻辑，你可以选择两种更合理的方案，无需在每个查询方法中重复写.Where(...)条件。 #

方案1：EF Core 全局查询过滤器（最推荐） #

这是EF Core原生支持的全局过滤能力，配置后所有针对Category的查询都会自动带上用户匹配条件，完全不用修改现有业务查询代码。
操作步骤：

1. 先在项目启动配置中注册IHttpContextAccessor，用于获取当前登录用户信息：

// Program.cs
builder.Services.AddHttpContextAccessor();

2. 修改AppDbContext，注入IHttpContextAccessor并配置全局过滤规则：

public class AppDbContext : IdentityDbContext
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public AppDbContext(DbContextOptions<AppDbContext> options, IHttpContextAccessor httpContextAccessor) 
        : base(options)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    // 获取当前登录用户Id
    private string? CurrentUserId => _httpContextAccessor.HttpContext?.User.FindFirstValue(System.Security.Claims.ClaimTypes.NameIdentifier);

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        // 给Category实体配置全局查询过滤器
        modelBuilder.Entity<Category>()
            .HasQueryFilter(c => c.UserId == CurrentUserId);
    }

    public DbSet<Category> Categories { get; set; }
}

如果后续有管理员需要查询全量数据的场景，只需在查询时加上IgnoreQueryFilters()即可跳过过滤：

var allCategories = context.Categories.IgnoreQueryFilters().ToList();

方案2：仓储层封装统一查询入口 #

如果你不想在DbContext层面加全局规则，也可以在你的SQLExpenseRepository里封装统一的过滤后数据集，所有内部查询都走这个入口，避免重复写过滤条件：

1. 首先给仓储注入IHttpContextAccessor获取当前用户Id：

private readonly AppDbContext context;
private readonly string? _currentUserId;

public SQLExpenseRepository(AppDbContext context, IHttpContextAccessor httpContextAccessor)
{
    this.context = context;
    _currentUserId = httpContextAccessor.HttpContext?.User.FindFirstValue(System.Security.Claims.ClaimTypes.NameIdentifier);
}

// 封装统一的过滤后数据集，所有查询都用这个属性代替context.Categories
private IQueryable<Category> UserCategories => context.Categories.Where(c => c.UserId == _currentUserId);

2. 后续业务查询直接使用UserCategories即可：

// 示例：获取当前用户所有启用的分类
public List<Category> GetActiveCategories()
{
    return UserCategories.Where(c => c.IsActive).ToList();
}

为什么不推荐在构造函数里做过滤？ #

理论上你可以在构造函数里把过滤后的IQueryable存为私有字段，但存在几个明显问题：

• 依赖DI容器解析仓储时HttpContext已经完全就绪，如果生命周期不匹配很容易拿到空的用户Id
• 过滤逻辑硬编码在仓储里，完全丧失灵活性，后续需要查全量数据的场景无法支持
• IQueryable是延迟执行的，构造函数中定义的过滤条件如果后续上下文变化可能出现预期外的行为

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