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% 的数据库性能救火时间。
