17370845950

EF Core上线前必须落实五项规范：DbContext依赖注入+池化、禁用敏感日志、SaveChanges批量提交、只写场景关闭自动追踪、千条以上数据使用BulkExtensions批量库。

EF Core 用得顺不顺，关键不在会不会写 Add 或 SaveChanges，而在于结构是否合理、行为是否可控、性能是否留有余量。下面这些不是“可选技巧”，而是上线前该默认落地的规范动作。

DbContext 生命周期必须用依赖注入 + 池化

每次 HTTP 请求（或一个业务单元）创建一个新 DbContext 实例，这是底线。不要手动 new，更不要跨请求复用。

• 在 Program.cs 中注册池化版本，例如：
  services.AddDbContextPool(options => options.UseSqlServer(connStr), poolSize: 128);
• 池化能显著降低对象创建/释放开销，尤其在高并发 Web 场景下；poolSize 值建议从 64 起调，按压测结果逐步上浮
• 禁用敏感日志：options.EnableSensitiveDataLogging(false)（生产环境必须关）

SaveChanges 必须批量提交，禁止循环内调用

每调一次 SaveChanges() 就启一个事务、走一次网络往返、触发一次变更检测——这是最常被忽略的性能黑洞。

• 新增多条记录：用 context.AddRange(entities) 替代循环中 Add()
• 更新多条：优先用 UpdateRange()；若需条件更新，考虑原生 SQL 或 ExecuteUpdateAsync（EF Core 7+）
• 删除同理：用 RemoveRange()，避免先查再删

只写不读场景要关闭自动追踪

如果你只是导入数据、写日志、同步消息，根本不需要 EF Core 去跟踪实体状态，那就别让它干这活。

• 插入前加一句：context.ChangeTracker.AutoDetectChangesEnabled = false;
• 插入完成后再恢复（如需后续操作）：context.ChangeTracker.DetectChanges();
• 注意：AsNoTracking() 是查询阶段用的，对 SaveChanges 无直接影响

千条以上数据插入必须用批量库

EF Core 原生 SaveChanges 是逐条 INSERT，1000 条 ≈ 1000 次 round-trip。真实业务里，初始化、迁移、报表导出等场景动辄上万条。

• 推荐 EFCore.BulkExtensions（支持 SQL Server / PostgreSQL / SQLite）
• 一行代码替代：context.BulkInsert(entities);，速度提升 10–100 倍很常见
• 注意事务边界：Bulk 方法通常自带事务，无需外层再包 BeginTransaction，除非要和其它 EF 操作强一致

基本上就这些。不复杂，但容易忽略。项目初期定好这几条，后期省掉 80% 的数据库性能救火时间。