EF Core 可通过禁用跟踪、重写 SaveChanges、DI 分离读写上下文及数据库权限控制实现只读 DbContext；最常用的是 AsNoTracking() 和全局 NoTracking 配置，配合抛出异常的 SaveChanges 重写与 Scoped 读写上下文注册。
EF Core 本身没有内置的“只读 DbContext”类型，但可以通过配置让 DbContext 实际以只读方式运行——即禁止跟踪、禁用变更检测、跳过 SaveChanges，从而避免意外写入。关键不是“创建只读类”，而是控制行为。
1. 禁用实体跟踪（最常用且有效）
通过 AsNoTracking() 或全局设置默认不跟踪，可避免 EF 加载实体后参与变更追踪，大幅降低内存开销并天然防止误更新。
- 查询时显式调用：
context.Users.AsNoTracking().ToList() - 全局配置（在
OnConfiguring中）：optionsBuilder.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking) - 注意：不跟踪不影响导航属性加载（如
Include），但关联实体也不会被跟踪
2. 重写 SaveChanges 系列方法强制拒绝写入
在 DbContext 派生类中覆盖 SaveChanges 和 SaveChangesAsync，直接抛出异常或返回 0，确保任何提交操作都失败。
- 推荐做法：在构造函数中传入只读标志，或通过 DI 注入不同生命周期的上下文实例
- 示例重写：
public override int SaveChanges(bool acceptAllChangesOnSuccess)
{
throw new InvalidOperationException("只读上下文不允许执行 SaveChanges。");
}
public override async Task<int> SaveChangesAsync(bool acceptAllChangesOnSuccess, CancellationToken cancellationToken = default)
{
throw new InvalidOperationException("只读上下文不允许执行 SaveChangesAsync。");
}
3. 配合依赖注入区分读写上下文
注册两个 DbContext 类型（或同一类型但不同命名服务），分别用于读和写，避免混用。
- 定义两个生命周期作用域（如 Scoped）：
AddDbContext<appreadcontext>(...)</appreadcontext>和AddDbContext<appwritecontext>(...)</appwritecontext> - 在
AppReadContext中启用NoTracking并禁用 SaveChanges；AppWriteContext则保持默认 - 控制器或服务中按需注入对应上下文，语义清晰、职责分离
4. 可选：数据库层面限制（增强安全性）
仅靠代码不能完全杜绝写入风险，建议配合数据库权限控制：
- 为只读应用分配仅含
SELECT权限的数据库用户 - SQL Server 可设为只读数据库（
ALTER DATABASE ... SET READ_ONLY），但会影响所有连接 - PostgreSQL 可通过
REVOKE INSERT, UPDATE, DELETE精确控制
基本上就这些。不需要魔改 EF Core，也不必引入额外库——合理组合跟踪策略、SaveChanges 控制和 DI 分离，就能安全、高效地实现只读 DbContext 场景。
