ef core值对象必须显式配置ownsone/ownsmany，否则查出为null；record比class更安全；hascolumnname需谨慎选策略；[owned]特性缺乏细粒度控制，推荐fluent api配置。
EF Core 值对象不是“加个特性就能用”，必须显式配置 OwnsOne 或 OwnsMany，否则它会被当成普通引用属性忽略——查出来永远是 null，哪怕数据库字段有值。
为什么 Address 属性总是 null，但数据库里明明有数据？
这是最常踩的坑：EF Core 默认不加载 Owned Type，哪怕它和实体在同一个表里。它不像导航属性那样能被懒加载，也不像普通字段自动填充。
- 查询时没写
Include(o => o.ShippingAddress)→ShippingAddress为null，即使所有列都存着值 - 用了
AsNoTracking()但没Include→ 同样为null（AsNoTracking不影响加载逻辑，只影响跟踪） - 用
Select投影到匿名类型或 DTO → 可以取到值，但得不到可跟踪的Address实例
根本原因：Owned Type 的加载是显式契约，不是隐式行为。EF Core 不会扫描属性类型然后“猜”你要不要加载。
定义值对象类时，record 和 class 有什么实际区别？
关键不在语法糖，而在 EF Core 对构造和赋值的约束。
- 用
record：自动带init属性 + 值语义 + 无参构造被禁用 → 更安全，推荐 - 用
class：必须手动删掉 public 无参构造函数，否则 EF Core 可能误判为实体；否则迁移会生成独立表或报错 - 所有属性必须有
set或init，只读属性（如public string FullAddress => $"{Street}, {City}";）无法被 EF Core 设值 → 加载时该属性被跳过，静默为null或默认值 - 若用私有字段 + 公共属性，需配
Property(a => a.Street).HasField("_street")，否则映射失败
OwnsOne 配置里，HasColumnName 和前缀规则怎么选？
列名策略直接影响数据库结构和后续维护成本，不是纯 cosmetic 问题。
- 不调用
HasColumnName：EF Core 默认用OwnerProperty_NestedProperty格式，比如ShippingAddress_Street→ 表字段名长、易重复、难改 - 显式调用
HasColumnName("ShipStreet")：字段名干净，但必须为每个属性单独写，且要确保不冲突（比如两个OwnsOne都用了Street） - 更稳妥的做法是统一前缀：
sa.ToTable("Orders").OwnsOne(..., sa => { sa.Property(x => x.Street).HasColumnName("ShipStreet"); }) - 如果值对象嵌套（如
Address包含GeoLocation），必须链式调用OwnsOne(a => a.Location)，不能省略 —— 否则内层字段不会映射
为什么不能用 [Owned] 特性代替 Fluent API？
[Owned] 看似简单，但隐藏了关键限制，容易导致后期重构困难。
-
[Owned]是全局声明，无法按实体差异化配置：同一个Address类，在Customer里要MaxLength(100)，在Vendor里要MaxLength(255)→ 必须用OwnsOne分开配 - 无法控制列名前缀或是否映射某字段：
[Owned]下所有属性全量映射，没有开关 - 不支持嵌套 Owned Type 的细粒度控制（比如只对某一层禁用某个属性）
- 团队协作中，配置散落在类定义和
OnModelCreating两处，可维护性差
真正需要“开箱即用”的场景极少；多数业务系统里，一个值对象在不同上下文中字段约束、存储格式、甚至是否启用都不同 —— 这正是 Fluent API 存在的理由。
