在 SaveChanges 或 SaveChangesAsync 中调用 DetectChanges 后遍历 ChangeTracker.Entries()，筛选实现 ITrackTime 接口的 Added/Modified 实体，分别设置 CreatedAt/UpdatedAt 为 DateTime.UtcNow，避免依赖数据库生成或硬编码反射。
SaveChanges 拦截器里怎么拿到待保存的实体
EF Core 6+ 提供了 SaveChangesInterceptor，但它不直接暴露变更实体列表；真正能安全遍历待提交实体的地方是重写 DbContext.SaveChanges 或使用 SaveChangesAsync 的 override 版本。拦截器更适合做日志、异常包装等横切操作，自动更新时间这类逻辑建议放在 SaveChanges 调用前统一处理。
关键点：调用 ChangeTracker.DetectChanges() 确保状态最新，再遍历 ChangeTracker.Entries() 获取所有 Added 和 Modified 实体。
如何识别并更新 CreatedAt / UpdatedAt 字段
不能硬编码字段名去反射赋值，否则耦合严重、易出错。推荐定义接口约束，比如：
public interface ITrackTime
{
DateTime CreatedAt { get; set; }
DateTime UpdatedAt { get; set; }
}然后在 SaveChanges 中统一处理：
- 对
Added实体：设置CreatedAt和UpdatedAt为当前时间（如DateTime.UtcNow） - 对
Modified实体：只更新UpdatedAt，避免覆盖原有CreatedAt - 跳过未实现
ITrackTime的实体，保持兼容性
为什么不用 ValueGeneratedOnAdd / OnUpdate 配置
数据库端生成（如 SQL Server 的 GETUTCDATE()）看似省事，但有明显缺陷：
- 应用层无法在保存前读取到生成的时间值，影响后续业务逻辑（比如日志、缓存键计算）
- 并发场景下，若多个实体依赖同一时间戳，数据库生成会导致微小偏差
- 单元测试难模拟，因为绕过了 C# 层控制
-
ValueGeneratedOnAddOrUpdate在 EF Core 中并不存在，官方不支持“修改时自动生成”这种混合策略
要注意的坑：并发修改、软删除、导航属性
实际项目中容易漏掉这些情况：
- 手动调用
Entry(entity).State = EntityState.Modified时，ChangeTracker可能不会标记所有属性为已修改，导致UpdatedAt更新失败 —— 建议改用Attach+ 显式Property(...).IsModified = true - 软删除实体（如含
IsDeleted字段）通常也需更新UpdatedAt，别只判断Added/Modified - 导航集合里的子实体不会被父实体的
SaveChanges自动触发时间更新，必须确保子类也实现ITrackTime，并在同一轮遍历中被捕获 - 如果用了
AsNoTracking()查询后直接修改再Update()，要确认实体确实进入了Modified状态，否则时间字段不会更新
最稳妥的做法是把时间更新逻辑封装成一个可复用的方法，在每个 SaveChanges 入口调用，而不是依赖某一种配置或拦截时机。
