EF Core 连接数据库前必须配对 DbContext 和 DbSet，否则编译或运行时报错；DbContext 需继承并配置选项，DbSet 命名用复数；SQLite 路径需绝对或拼接；SaveChanges() 才真正写库，推荐异步；避免客户端求值，开启日志查 SQL；迁移需 Design 包和正确项目指定。
EF Core 连接数据库前必须配对
和
不配好这两样，连
都可能报错，更别说查数据了。常见错误是只建了实体类，没在
里声明
，结果调用
时直接编译失败或运行时报
。
类必须继承自
，且重写
或通过 DI 注入
每个要映射的表对应一个
属性，命名习惯用复数（如
）
如果用 SQLite，连接字符串里路径要写绝对路径或用
拼接，否则迁移时找不到文件
不自动提交事务，
版本叫
很多人以为调了
就立刻入库了，其实只是加进变更跟踪器；真正写库靠
。漏掉这句，数据永远不落地。
同步方法阻塞线程，Web API 场景下建议统一用
配合
它默认开启事务，但不会跨多个
调用延续——两次调用之间出异常，第一次的修改已提交，没法回滚
批量插入别用循环 +
+
，性能极差；改用
再一次提交
查询时别在
上直接调
或
前做复杂 C# 运算
EF Core 翻译 SQL 有边界，比如
能转，但
会触发客户端求值（ClientEvaluated），小数据看不出问题，大数据量时整张表拉到内存再过滤，CPU 和内存都爆。
C知道
CSDN推出的一款AI技术问答工具
下载
优先用 EF 支持的函数：比如
替代
，
替代
不确定是否服务端执行？打开日志看生成的 SQL：
加在
后
需要复杂逻辑又绕不开客户端处理？显式用
切换上下文，但得清楚这是主动放弃 SQL 下推
迁移命令依赖
包和正确的启动项目
报 “No project was found” 或 “Unable to retrieve project metadata”，大概率不是命令写错，而是环境没对齐。
确保目标项目（含
的那个）已安装
—— 运行时不需要，但迁移工具强依赖它
如果解决方案里有多个项目，
和
必须指定清楚：
SQLite 不支持所有迁移操作（比如改列类型），
生成的 SQL 可能含
，直接执行会失败
关系映射看着简单，但外键配置、级联删除策略、索引定义这些细节，一不留神就让
报错或查不出预期数据。动手前先跑通一个带主从表的最小迁移+查询闭环，比对着文档抄十段代码管用。
DbContextDbSetdotnet runDbContextDbSetcontext.UsersNullReferenceExceptionDbContextMicrosoft.EntityFrameworkCore.DbContextOnConfiguringDbContextOptionsDbSetpublic DbSet Products { get; set; } AppContext.BaseDirectorySaveChanges()asyncSaveChangesAsync()context.Add(new Order())SaveChanges()SaveChangesAsync()awaitSaveChangesAdd()SaveChanges()context.AddRange()IQueryable.ToList().First()DateTime.Now.AddDays(7)user.Name.ToUpper().Contains("ADMIN")EF.Functions.Like()string.Contains()DateTime.UtcNowDateTime.Nowoptions.LogTo(Console.WriteLine)UseSqlServer.AsEnumerable()Microsoft.EntityFrameworkCore.Toolsdotnet ef migrations add InitDbContextMicrosoft.EntityFrameworkCore.Design--project--startup-projectdotnet ef migrations add Init --project DataProject --startup-project WebApiProjectdotnet ef migrations scriptALTER COLUMNSaveChanges