你是对的，optionsAction在

IServiceCollection.AddDbContext<TContext>(Action<DbContextOptionsBuilder>? optionsAction)

可以是Action<DbContextOptions>。
然而，Entity Framework Core的“配置操作”（由于缺乏更好的术语，这不是“options pattern”）比一般的依赖注入配置方法复杂得多。
您通常不会完成设置一两个字符串（如身份验证cookie）以及可能的操作或转换器（想到JSON），但实体框架核心有非常复杂的配置场景。
因此，与documented in the DbContextOptionsBuilder class一样，它：
提供用于配置DbContextOptions的简单API图面。数据库（和其他扩展）通常在此对象上定义扩展方法，这些方法允许您配置要用于上下文的数据库连接（和其他选项）。
它隐藏了构建器内部的可扩展性所需的所有管道，而不是DbContextOptions本身。构建器管道仅在构建时需要，而选项本身一旦构建，将在运行时使用。
另请参阅MS Learn：DbContext配置和初始化：DbContextOptions：
这些Use* 方法是由数据库提供程序实现的扩展方法。这意味着必须先安装数据库提供程序NuGet包，然后才能使用扩展方法。
并且：
特定于数据库提供程序的可选配置在其他特定于提供程序的生成器中执行。例如，在连接到Azure SQL时，使用EnableRetryOnFailure配置重试以实现连接弹性
在Use*方法中发生的一切都被用来 * 构造DbContextOptions*。您不会希望自己这样做，也不会希望Options类包含太多仅与其设置相关的管道，而不是在构造后使用。