DbContext被过早释放导致调用已销毁实例，根源在于生命周期管理不当：默认Scoped下需避免静态/单例存储、手动Dispose、跨scope异步使用及延迟执行IQueryable；应构造函数注入、显式创建scope、立即执行查询。
这个错误本质是试图在 DbContext 已被释放后继续调用其方法，比如执行查询、保存变更或访问 DbSet。根本原因不是代码写错了，而是 DbContext 的生命周期没管好——它被过早释放了，而后续逻辑还在等着用它。
DbContext 默认是 Scoped 生命周期
在 ASP.NET Core 中，通过 services.AddDbContext() 注册的 DbContext 默认注册为 ServiceLifetime.Scoped。这意味着：它在每个请求（scope）内创建一次，请求结束时自动释放。只要你在控制器、服务等 scoped 依赖中正常使用，一般不会出问题。
- ✅ 正确：在 Controller 的构造函数中注入 DbContext，然后在 Action 方法里查数据
- ❌ 错误：把 DbContext 存到静态字段、单例服务里，或者手动调用 Dispose() 后还继续用
- ⚠️ 隐患：在异步操作（如 Task.Run、.ContinueWith）中跨 scope 使用 DbContext，容易掉进“已释放”陷阱
别手动 new DbContext 或调用 Dispose()
DbContext 不是普通类，它背后管理着连接、变更追踪、内部状态。手动 new 它绕过了 DI 容器的生命周期管理；手动调用 Dispose() 则可能提前终结它的生命，尤其在 scoped 场景下会破坏整个请求 scope 的一致性。
- 避免 new AppDbContext() —— 改为构造函数注入
- 不要在业务代码里写 context.Dispose() 或 using (var ctx = new …)（除非你明确在非 DI 环境如控制台程序中自己管理 scope）
- 如果真要短生命周期，用 IServiceScopeFactory 创建新 scope，再从中获取 DbContext
异步和延迟执行时特别小心
IQueryable 是延迟执行的。如果你返回一个未执行的 IQueryable，又在 DbContext 释放后才调用 .ToList()、.First() 等，就会触发“context has been disposed”。
