EF Core 的关系映射，说穿了不是靠“照着教程抄配置”搞定的，而是由实体定义、导航属性和（必要时）显式配置这三样东西共同决定的。只要你的实体类结构写对了，6.0 以上的版本基本不用手敲 modelBuilder，一对多和纯多对多就能跑通。下面咱们拆开细聊。
一对多：靠外键字段 + 导航属性自动发现
EF Core 默认就能识别一对多关系，前提是子实体里得有个明确的外键属性，并且两边都有对应的导航属性。举个例子，Post 必须有个 BlogId 字段，Blog 那边要有 ICollection，Post 这边也得有 Blog 引用——这四样凑齐了，你执行 dotnet ef migrations add 的时候，EF 就会自动生成带外键约束的表结构。
BlogId必须是非空类型（比如int而不是int?），否则关系会被当成“可选”，数据库里外键列就允许 NULL，语义上就不对了。- 如果子实体没写
Blog导航属性，只留了BlogId和父类的ICollection，EF 虽然也能建模，但查数据时就没法用Include做预加载了，查询体验会打折扣。 - 除非你要改默认行为（比如指定备用键），否则别在
OnModelCreating里手动调用HasOne/WithMany去“强化”这个关系——那属于画蛇添足。
纯多对多：EF Core 6+ 隐式中间表，删干净再跑迁移
如果两个实体都只含 ICollection 导航属性，没有中间类，也没有外键字段，EF Core 6.0 以上就会自动生成一张中间表（比如 PostsTags），带复合主键，不生成额外的 ID 列。这设计很省事，但有几个坑得提前知道。
- 动手之前，一定要删掉旧的中间实体类（比如
PostTag）和对应的DbSet，否则模型构建会失败，报错信息往往像Unable to determine the relationship represented by na vigation 'Post.Tags'，指向不明，排查起来很费时间。 - 两边的
ICollection属性名不必对称，但类型必须是对方实体，并且不能含任何外键字段（比如PostId、TagId）——中间表是 EF 自动管理的，你不需要手动干涉。 - 中间表名默认按字母顺序拼接（
PostsTags而不是TagsPosts），这个顺序不可控。如果你非要定制表名，那就只能退回到显式建模了。
多对多带附加字段：必须用显式中间实体
一旦中间表需要存时间、状态、权重这类业务字段，隐式方式就立马失效了。你得亲手建一个中间类（比如 PostTag），然后分别配两段一对多关系。
- 中间类必须有主键（可以是
Id单独字段，也可以是复合键PostId + TagId），并且包含你要存的业务字段（比如CreatedTime、IsPrimary）。 Post和Tag类里不再直接引用对方，而是各有一个ICollection。- 在
OnModelCreating中要分别写两段配置：entity.HasOne(pt => pt.Post).WithMany(p => p.PostTags)和entity.HasOne(pt => pt.Tag).WithMany(t => t.PostTags)。注意，这里的关系已经变成了两个独立的一对多，而不是多对多。 - 查询打标签记录时，必须走
PostTag实体，不能直接post.Tags——导航属性已经变了，习惯要跟着改。
最后说一个最常见的陷阱：隐式多对多和显式中间实体不能共存。哪怕你只残留了一个 PostTag 类，或者一个 PostTag 的 DbSet，EF 就会拒绝生成迁移，而且错误信息往往不指向真实原因。动手前先全局 grep 一下，把相关类、DbSet 全部删干净，比反复调试要快得多。
