为什么在DbContext中使用Dependency Injection而非OnConfiguring方法？

你提到的两种实现分别对应硬编码配置和依赖注入配置两种方案：

方案1：重写OnConfiguring（不推荐） #

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseMySQL("...");
}

方案2：依赖注入DbContextOptions（推荐） #

public StudentDbContext(DbContextOptions<StudentDbContext> context) : base(context)
{

}

推荐使用第二种方案的核心原因如下：

• 配置灵活度更高：使用DI注入配置的方式，你可以根据不同运行环境（开发/测试/生产）自由切换数据库配置、甚至切换数据库类型，不需要修改DbContext本身的代码。如果配置写死在OnConfiguring中，每次切换环境都要修改上下文类，容易出现漏改、错改的问题。
• 符合单一职责设计原则：DbContext的核心职责是管理实体映射、实现数据库操作逻辑，不应该承担数据库配置、连接字符串管理的职责。用DI的方式可以将配置逻辑统一托管在启动配置文件中，上下文类只需要关注自身核心功能，代码可维护性更强。
• 单元测试更便捷：做单元测试时你可以直接通过DI注入内存数据库的配置，不需要修改DbContext的代码就能完成测试。如果配置写在OnConfiguring中，你需要额外加环境判断逻辑才能适配测试场景，否则测试时必须连接真实数据库，效率低还容易污染正式数据。
• 生命周期托管更安全：在ASP.NET Core中DI框架会自动管理DbContext的生命周期，默认是Scope级别，每次请求创建一个实例，请求结束后自动释放，无需手动管理Dispose逻辑，能有效避免数据库连接泄漏、并发访问冲突等问题。如果自行在OnConfiguring中初始化，你需要手动控制实例的创建和销毁，很容易出现资源泄漏问题。
• 规避敏感信息泄露风险：写在OnConfiguring中很容易出现连接字符串、数据库账号密码硬编码的问题，一旦代码提交到仓库就会造成敏感信息泄露。使用DI的方式可以将配置存在appsettings.json、环境变量或者专用密钥管理服务中，不需要将敏感信息写死在业务代码里。

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