影子属性需在OnModelCreating中用modelBuilder.Entity<T>().Property<DateTime>("CreatedTime")显式声明，不可仅靠注解；SaveChanges前须手动通过CurrentValues["CreatedTime"]赋值；迁移时需配合HasDefaultValue确保列非空；并发场景下建议数据库侧维护UpdateTime更可靠。
EF Core 影子属性怎么声明和触发赋值
影子属性不是类里定义的字段，EF Core 自己“记住”的列，比如 CreatedTime、UpdatedTime。它不占实体类空间，但会出现在数据库表里，也参与变更追踪。
必须在 OnModelCreating 里用 modelBuilder.Entity<T>().Property<DateTime>("CreatedTime") 声明；不能只靠注解或约定自动识别 —— EF Core 不会猜你想要影子属性。
常见错误：只加了 [DatabaseGenerated(DatabaseGeneratedOption.Computed)] 却没在模型配置里注册，结果迁移生成失败，或运行时报 InvalidOperationException: The property 'CreatedTime' was not found。
- 影子属性名区分大小写，写成
"createdtime"和实体里期望的CreatedTime对不上，SaveChanges 时不会填充 - 类型必须匹配数据库兼容类型（如 SQL Server 不支持
DateTimeOffset默认值，用DateTime更稳妥） - 若同时用
ValueGeneratedOnAdd()和ValueGeneratedOnAddOrUpdate()，后者会覆盖前者，导致新建时不设值
如何在 SaveChanges 前自动填充影子属性值
EF Core 不会自动给影子属性赋业务时间（比如 DateTime.Now），得自己拦截 SaveChanges。推荐重写 DbContext.SaveChanges，而不是依赖数据库默认值 —— 后者无法保证时区一致，且修改操作拿不到客户端时间。
关键点：遍历 ChangeTracker.Entries()，对 Added 或 Modified 状态的实体，用 Entry.CurrentValues["CreatedTime"] 直接写入值。注意不能用 Entry.Property("CreatedTime").CurrentValue = ...，因为影子属性没有强类型 Property 方法。
- 只对状态为
EntityState.Added的实体设CreatedTime，避免重复覆盖 -
UpdatedTime应在Added和Modified两种状态下都更新，但别在Deleted时误触 - 如果用了并发令牌（
RowVersion或Timestamp），确保时间赋值发生在并发检查之前，否则可能引发乐观并发异常
影子属性 + 迁移脚本生成要注意什么
影子属性不会自动出现在 Add-Migration 生成的脚本里，除非你在 OnModelCreating 中明确配置了 IsRequired() 或 HasDefaultValueSql() 等约束。否则迁移可能漏掉该列，或建表时允许 NULL —— 而你代码里又假设它必有值，导致后续查询出空引用。
建议显式设置：HasDefaultValue(DateTime.UtcNow)（数据库侧兜底），再配合代码层赋值（应用侧主控）。两者不冲突，反而是安全冗余。
- SQL Server 上用
GETUTCDATE()，PostgreSQL 用CURRENT_TIMESTAMP，别混用 - 如果已有表，新增影子属性后首次迁移会报错 “column cannot be added to table because it does not allow nulls”，此时要手动补
HasDefaultValue(...)或在迁移中加AlterColumn设默认值 - 用
dotnet ef migrations script生成 SQL 时，确认输出里真包含了ADD COLUMN语句，别只信 C# 配置
为什么 UpdateTime 在并发更新时容易错乱
影子属性的 UpdatedTime 如果只靠 SaveChanges 拦截赋值，遇到并发修改（比如两个请求几乎同时改同一行），第二个请求可能把第一个刚写入的 UpdatedTime 又覆盖成自己的时间，逻辑上没问题，但丢失了“谁最后改”的精确顺序 —— 尤其当业务需要审计日志还原操作链时，这个时间戳就不可靠了。
更稳的做法是：把 UpdatedTime 改成数据库计算列（HASDEFAULT + ON UPDATE CURRENT_TIMESTAMP），或者用触发器/存储过程控制。EF Core 层只读不写，避免应用层时间偏差和竞争。
- SQL Server 不原生支持 ON UPDATE，得用触发器或默认值 + 计算列模拟
- PostgreSQL 可直接用
ON CONFLICT ... DO UPDATE SET updated_at = NOW()配合 upsert 场景 - 若坚持 EF Core 全权管理，至少把时间赋值逻辑提到事务最开始（比如在
BeforeSaveEntities事件里），而非等到底层执行前一刻
影子属性看着轻量，但时间类字段一旦牵扯到并发、时区、迁移、审计，每个环节都得对齐数据库行为和应用预期 —— 少一个 HasDefaultValue 或多一次 CurrentValues["xxx"] 写错位置，后面查问题能绕三圈。
