17370845950

EF Core 在 Azure Functions 中不能直接注入 DbContext，因其非线程安全且不支持跨调用复用；应每次执行时用 using 创建并及时释放实例，避免静态/单例缓存。

EF Core 可以在 Azure Functions 中使用，但要注意生命周期和连接管理——它不能像在 ASP.NET Core 那样自动注册为 Scoped 服务，必须手动控制 DbContext 实例的创建与释放，避免连接泄漏或并发问题。

为什么不能直接注入 DbContext？

Azure Functions 默认是无状态、短生命周期的执行模型，而 EF Core 的 DbContext 不是线程安全的，也不适合跨函数调用复用。若在静态上下文或单例中缓存 DbContext，会导致异常或数据不一致。

• 每次函数执行应创建独立的 DbContext 实例
• 务必在函数结束前调用 Dispose() 或使用 using 语句
• 不要在函数类级别声明 DbContext 字段（易引发共享冲突）

推荐做法：按需创建并显式释放

在函数方法体内新建 DbContext，并通过 Cosmos DB 提供程序（或其他目标数据库）配置连接字符串。适用于 HTTP 触发器、队列触发器等常见场景。

• 从 IConfiguration 或环境变量读取 Cosmos 连接字符串
• 用 new MyDbContext(options) 构造上下文，不依赖 DI 容器
• 配合 using var context = new MyDbContext(...); 确保及时释放
• 若需复用逻辑，可封装为工厂方法，但不缓存实例

结合 Cosmos DB 输出绑定（简化写入）

对于仅写入 Cosmos DB 的场景，可跳过 EF Core，改用 Azure Functions 原生的 Cosmos DB 输出绑定——无需写 DbContext 代码，只需定义 POCO 类，绑定会自动序列化为 JSON 并存入容器。

• 适用于“只进不出”或简单结构化写入
• 在 function.json 或 C# 特性中声明 CosmosDBOutput 绑定
• 比 EF Core 更轻量，也更符合 Functions 的无状态设计
• 如需查询、事务、变更跟踪等功能，仍需 EF Core

进阶：自定义 IServiceProvider 支持 Scoped 注入（谨慎使用）

可通过扩展 Functions 的启动逻辑（如实现 IWebJobsStartup），注册 EF Core 服务并启用作用域。但要注意：

• 每个函数执行需手动创建新作用域：using var scope = host.Services.CreateScope();
• 仅在 .NET 6+ 和支持依赖注入的 Functions v4+ 中稳定可用
• 增加复杂度，调试成本上升，小项目不建议
• 必须确保所有异步操作都在同一作用域内完成

基本上就这些。核心就一条：别让 DbContext 活过单次函数执行。用完即弃，干净利落。