在使用Entity Framework Core操作关系型数据库时，null值的处理贯穿模型定义、数据保存和查询翻译多个环节。很多运行时异常和隐性数据错误，根源都在于没有理清EF Core对null的映射与转换逻辑。本文从模型配置、保存行为和查询表达式三个维度，详细说明EF Core处理null值的正确方式。
一、模型定义阶段的null映射规则
EF Core在根据实体类生成数据库模型时，会依据CLR类型的可空性来决定数据库列是否允许null。对于引用类型（如string、byte[]），默认映射为可空列；对于值类型（如int、DateTime），只有显式声明为可空值类型（如int?、DateTime?）才会生成可空列，否则迁移时会创建NOT NULL约束。
这种映射关系在迁移文件中是固定的，并不受运行时代码中是否赋null影响。如果实体里写的是int而非int?，即便你希望某条记录不填该字段，保存时也会因数据库约束报错。因此，是否允许null应当在实体设计阶段就明确。
public class User
{
public int Id { get; set; }
// 引用类型，默认可空
public string? Name { get; set; }
// 值类型，不加问号则数据库列NOT NULL
public int Age { get; set; }
// 可空值类型，数据库列允许NULL
public DateTime? LastLogin { get; set; }
}
也可以通过Fluent API显式控制，避免依赖默认约定。使用IsRequired(false)可声明列可选，IsRequired()则强制非空，这在团队约定比类型符号更直观时很有用。
modelBuilder.Entity<User>()
.Property(u => u.Name)
.IsRequired(false); // 对应数据库可空
modelBuilder.Entity<User>()
.Property(u => u.Age)
.IsRequired(); // 对应数据库NOT NULL
二、保存数据时的null行为
当通过DbContext添加或修改实体时，EF Core的变更跟踪器会记录属性的当前值。如果某个属性被设置为null，且对应列允许null，SaveChanges就会将DBNull写入数据库。这里要注意的是，对于未显式赋值的可空属性，EF Core通常将其视为null，而不是忽略该列。
但在断开式场景（如先new实体再Attach）中，若属性保持类型默认值且未被标记Modified，EF Core可能不会生成该列的UPDATE语句，从而让数据库保留旧值而非写成null。此时需要手动调用Property().IsModified = true，或使用Entry().CurrentValues.SetValues()来强制同步。
var user = new User { Id = 1, Name = null, Age = 20 };
context.Attach(user);
// 明确告知Name被修改，确保UPDATE包含Name=null
context.Entry(user).Property(u => u.Name).IsModified = true;
await context.SaveChangesAsync();
另外，在级联删除与null外键的处理上，若外键属性设为null且配置了可选关系，EF Core会将子表外键置空而不是删除子记录。这与数据库ON DELETE SET NULL行为一致，但前提是关系在模型中声明为可选（HasOne().WithMany()，无IsRequired）。
三、查询表达式中null的翻译
LINQ to Entities会把C#的null比较翻译成SQL的IS NULL或IS NOT NULL，而不是普通的等号运算。直接写Where(u => u.Name == null)会得到预期结果，但涉及可空值类型与常量混合比较时，C#编译器的类型提升规则可能导致LINQ树与直觉不符。
例如对int?字段，若用u.Age == (int?)null或先定义局部变量再比较，通常能稳定翻译；而把null直接赋给隐式类型变量再比较，有时会被EF Core判定为常量null从而正确翻译，有时则因客户端求值而拉取全表。明确使用可空类型能减少歧义。
// 正确：翻译为 SQL Age IS NULL
var list = await context.Users
.Where(u => u.LastLogin == null)
.ToListAsync();
// 可空值类型显式比较
int? threshold = null;
var list2 = await context.Users
.Where(u => u.Age == threshold)
.ToListAsync();
还需要注意，在EF Core中，对null使用string.IsNullOrEmpty这类方法会被翻译为SQL的NULL判断与空串判断的组合，而不是单纯null检查。如果只需要找null，应避免误用导致结果集偏差。
| LINQ写法 | SQL翻译倾向 | 说明 |
|---|---|---|
| u.Name == null | Name IS NULL | 仅查null |
| string.IsNullOrEmpty(u.Name) | Name IS NULL OR Name = '' | 含空字符串 |
| u.Age == null | Age IS NULL | 仅可空值类型有效 |
四、常见误区与建议
一个典型误区是认为运行时代码里不赋值就不会写null。实际上对于跟踪中的实体，未赋值的引用类型属性本来就是null，保存时就会写库；而对于脱离跟踪后重新Attach的实体，则需要手动标记修改。混淆这两种情况会造成“明明没写null却出现了null”或者“想写null却写了旧值”的问题。
建议在数据访问层封装统一的保存方法：新增时按模型默认值入库，更新时显式加载数据库实体做对比，只把真正变化的属性标记为Modified。这样null的写入与否完全由业务状态决定，而不是被变更跟踪的盲区干扰。
public async Task UpdateUserAsync(User dto)
{
var dbUser = await context.Users.FindAsync(dto.Id);
if (dbUser == null) return;
context.Entry(dbUser).CurrentValues.SetValues(dto);
// SetValues会自动处理null与变更的追踪
await context.SaveChangesAsync();
}
最后，数据库迁移前务必检查生成脚本里列的NULL/NOT NULL定义，与实体类型和Fluent配置核对一致。把null处理规则固化在模型和迁移中，比在业务代码里到处判空更可靠，也更容易维护。