EF Core处理NULL需模型定义、数据库配置和查询逻辑协同：实体属性须显式声明可空性（如string?、int?），迁移同步更新列约束，查询时主动防御NULL（如?.操作符、??默认值、自定义JSON转换器），EF Core 9启用UseRelationalNulls后需注意bool?等字段的比较逻辑。
EF Core处理NULL值的核心在于模型定义、数据库配置和查询逻辑三者协同。不是单靠某一个设置就能“自动兜底”，而是需要在C#实体、迁移脚本、查询写法上统一考虑。尤其在升级到EF Core 9后，UseRelationalNulls这类全局开关还会改变SQL生成行为，稍不注意就出错。
实体属性必须显式声明可空性
EF Core会根据C#类型的可空性（string?、int?、bool?）自动推断数据库列是否允许NULL。如果用string Name { get; set; }（非可空引用类型），EF Core默认认为该字段不允许NULL，即使数据库里是NULL，查询时也会抛出“Data is Null”异常。
- 字符串、引用类型：改用
string?，并确保启用C#的可空引用类型（#nullable enable） - 值类型（如
int、DateTime）：必须改为int?、DateTime?才能映射NULL - 若想保留非可空写法但允许数据库为NULL，需在
OnModelCreating中强制配置：
modelBuilder.Entity().Property(e => e.Email).IsRequired(false);
数据库迁移要同步更新列约束
改了C#模型只是第一步，必须通过迁移把数据库字段也改成允许NULL。否则应用能跑，但插入或更新时可能被数据库直接拒绝。
- 修改实体后运行：
dotnet ef migrations add MakeEmailNullable - 检查生成的迁移代码，确认
AlterColumn中包含nullable: true - 执行：
dotnet ef database update - 特别注意：MySQL中
NOT NULL转NULL是原地操作，但反过来会锁表；已有数据含NULL时，反向迁移可能失败
查询时主动防御NULL场景
左连接、外键关联、JSON列、条件筛选都容易带出NULL。EF Core不会帮你自动跳过或替换，得自己写安全逻辑。
- 左连接结果中导航属性可能为
null，访问前加?.Title或?? "N/A" - 模糊搜索参数可能为
null，用string.IsNullOrEmpty(x)配合三元判断，避免WHERE x = NULL这种无效条件 - JSON列（如
Attributes）解析失败常因值为NULL，建议用自定义转换器捕获并返回空集合，而不是让JsonSerializer.Deserialize直接炸掉 - EF Core 9开启
UseRelationalNulls()后，Where(x => x.IsActive == true)对bool?字段可能返回NULL而非true/false，建议显式写成x.IsActive == true || x.IsActive == null或改用HasValue && Value
JSON列与NULL兼容要单独处理
EF Core对JSON列的NULL支持较弱，默认转换器遇到NULL会抛异常，不是返回null或空对象。
- 简单方案：用内置
CollectionToJsonStringConverter，它内部已处理NULL → 空字符串逻辑 - 复杂对象：实现自定义
ValueConverter，ConvertToProvider中判空返回null，ConvertFromProvider中判空返回null或默认实例 - 更稳妥：在实体中把JSON属性设为
string?，业务层再手动反序列化，完全掌控NULL路径
基本上就这些。关键不是“怎么让EF Core接受NULL”，而是从模型设计开始就明确每个字段的NULL语义——该允许就放开，该禁止就加约束，该防御就写判断。不复杂但容易忽略。
