EF Core 连接字符串错误导致 DbContext 构建失败而非数据库连接失败；主键命名、表/字段映射需严格匹配默认规则或显式配置；只读查询应使用 AsNoTracking()；SaveChanges() 异常后必须丢弃当前 DbContext 实例。
EF Core 连接字符串写错会直接报 InvalidOperationException
不是连不上数据库，而是 EF 根本没机会发请求——它在构建 DbContext 实例时就炸了。常见错误是把 SQL Server 的连接字符串当成 SQLite 用，或者漏掉 Server=、Database= 这类必填项。
实操建议：
- SQL Server：确保连接字符串含
Server=your-server;Database=your-db;Trusted_Connection=true;（Windows 认证）或加User Id=xxx;Password=yyy; - SQLite：路径必须是绝对路径或用
|DataDirectory|占位符，比如Data Source=|DataDirectory|app.db，否则运行时找不到文件 - PostgreSQL（Npgsql）：需额外安装
Npgsql.EntityFrameworkCore.PostgreSQL包，且连接字符串格式和 SQL Server 完全不同，不能混用 - 检查
DbContext构造函数里传入的DbContextOptions是否真从ConfigureServices注入进来，而不是 new 出来的空配置
DbSet 属性名不等于表名，但默认映射规则很严格
EF Core 默认按类名复数化当表名（Blog → Blogs），字段名也默认按属性名直译。一旦命名不匹配，查询就返回空或抛 InvalidOperationException: The entity type 'X' requires a primary key to be defined.
实操建议：
- 主键必须叫
Id或Id BlogId），否则得用[Key]显式标记，或在OnModelCreating里配置HasKey(x => x.MyId) - 想让
Blog类映射到blog_info表？别改类名，用 Fluent API：modelBuilder.Entity().ToTable("blog_info"); - 字段名含下划线（如
created_at）？EF 不会自动转驼峰，要么数据库字段改名，要么用[Column("created_at")]贴属性上 - 忽略某个属性不映射？加
[NotMapped]，别靠注释或删属性——EF 看不到注释，删了编译都过不去
查数据时用 .AsNoTracking() 和不用，性能差好几倍
EF Core 默认开启变更跟踪（Change Tracking），每次查询都会把实体加入内部快照，方便后续 SaveChanges() 时对比修改。但如果你只是读取展示（比如后台管理列表页），这个开销纯属浪费，还可能引发意外更新。
实操建议：
- 只读场景一律加
.AsNoTracking()，尤其是分页查询大量数据时，内存占用和 GC 压力明显下降 - 需要更新再查一遍？别用同一个
DbContext实例反复查+改，先.AsNoTracking()查，再 new 一个新DbContext来改——避免状态污染 -
.AsNoTrackingWithIdentityResolution()是折中方案：不跟踪但保留引用相等性（比如同一行数据被查两次，仍返回同一个对象实例），适合需要局部对象复用但又不想全程跟踪的场景
SaveChanges() 报错后，DbContext 状态就不可信了
不是事务自动回滚完就万事大吉。EF Core 在 SaveChanges() 失败后，内部的变更追踪器可能卡在中间态：部分实体标记为 Modified，部分还是 Added，下次再调 SaveChanges() 很可能复现同样错误，甚至把不该提交的数据也塞进去。
实操建议：
- 捕获
DbUpdateException后，不要尝试“修复后重试”，直接丢弃当前DbContext实例，新建一个 - 需要原子性操作？显式用
using var transaction = context.Database.BeginTransaction();包裹，出错时transaction.Rollback()，然后仍要换新上下文 - 批量插入别用循环
Add()+ 一次SaveChanges()，大数据量时极慢。改用context.Blogs.AddRange(list)，或更彻底地用原生 SQL（context.Database.ExecuteSqlRaw()）或第三方库如EFCore.BulkExtensions
最常被忽略的是：DbContext 设计上就是短生命周期对象，不是单例，也不是静态工具类。把它当缓存用、跨线程共享、或长期持有，迟早踩进状态不一致的坑里。
