EF Core 的 DbContext 是怎么被创建和使用的
EF Core 不是靠静态方法调用的，核心入口是继承
DbContext的自定义类。你得先定义它，再通过依赖注入或手动 new（不推荐）来获取实例。没这个上下文，
DbSet<t></t>就只是个空壳。
常见错误：直接 new 一个
DbContext而没配置连接字符串或服务提供者，运行时抛
InvalidOperationException: No database provider has been configured。 必须在
Program.cs（.NET 6+）中调用
services.AddDbContext<appdbcontext>()</appdbcontext>，并传入连接字符串和数据库提供者（如
Microsoft.EntityFrameworkCore.SqlServer）
AppDbContext构造函数应接受
DbContextOptions<appdbcontext></appdbcontext>并传给基类，不能漏掉
: base(options)每个 HTTP 请求建议只用一个
DbContext实例（Scoped 生命周期），重复 new 或长期持有会导致追踪混乱和内存泄漏
DbSet 查询为什么有时不走 SQL，有时又报“无法翻译”
DbSet<t></t>表面像集合，实际是 IQueryable —— 它延迟执行，且 EF 会尝试把 C# 表达式树翻译成 SQL。但不是所有操作都能翻译，尤其涉及本地方法、复杂对象构造或未映射属性时。
典型现象：
Where(x => x.Name.ToUpper() == "ADMIN")在 SQLite 下可能成功，但在 SQL Server 上触发客户端评估警告；而
Where(x => MyHelper.IsSpecial(x.Id))直接报错
System.InvalidOperationException: The LINQ expression could not be translated。 优先用 EF 支持的表达式：比如
string.Equals(a, b, StringComparison.OrdinalIgnoreCase)比
a.ToLower() == b.ToLower()更易翻译 避免在查询中调用自定义方法、
new对象（除非是匿名类型或实体映射字段）、
DateTime.Now（改用
DateTime.UtcNow，EF 能识别） 不确定是否可翻译？加
.AsEnumerable()强制转为客户端执行（但会拉全表！仅调试用）
SaveChanges 和 SaveChangesAsync 的区别不只是同步异步
SaveChanges()是同步阻塞调用，会等数据库事务提交完成才返回；
SaveChangesAsync()是真正的异步，底层使用数据库驱动的 async I/O，不占用线程池线程。
容易踩的坑：在 ASP.NET Core 控制器里用了
SaveChanges()却声明了
async Task<iactionresult></iactionresult>方法，结果既没真正异步，又因未 await 导致状态机混乱或静默失败。 Web 应用一律用
await context.SaveChangesAsync()，不要混用同步方法 事务控制要显式：用
await context.Database.BeginTransactionAsync()，而不是靠
SaveChanges自动开启（它只在无事务时新建） 批量插入大量数据？别循环调
Add()+
SaveChanges()—— 每次都开事务。改用
context.AddRange()一次添加多个，再单次
SaveChanges
迁移（Migration）命令为什么总提示“无法访问项目”或“No migrations found”
EF Core 迁移命令（如
dotnet ef migrations add Init）需要同时知道两个东西：实体模型在哪（
--project）、DbContext 类型在哪（
--startup-project）。多数失败是因为路径或程序集解析错了。
典型报错：
Unable to retrieve project metadata. Ensure it's an SDK-style project或
No DbContext was found。 确保当前终端目录是含
.csproj的项目根目录；如果 DbContext 在类库，需用
--project指向该类库，
--startup-project指向 Web/Console 主项目 主项目必须引用 EF Core 设计时包：
Microsoft.EntityFrameworkCore.Design（开发时必需，非运行时） 迁移文件生成后，
dotnet ef database update才真正建表；别以为
migrations add就完事了
dotnet ef migrations add Init --project .\MyData.dll --startup-project .\MyWebApp.csproj
EF Core 的麻烦点不在语法多难，而在它横跨了对象模型、SQL 生成、生命周期管理和工具链四层。任何一个环节断开（比如 DbContext 注册漏了、迁移没指定 startup-project、查询用了不可翻译方法），都会表现为“不工作”，但错误信息往往藏在不同位置。动手前先确认这四层是否都连上了。
