EF Core 对
decimal和
double（或
float）的映射处理差异很大，核心在于：前者是**精确数值类型**，后者是**近似浮点类型**。配置不当容易导致精度丢失、查询不准确甚至数据库报错。
decimal 映射必须显式设精度和小数位
数据库中的
decimal类型（如 SQL Server 的
decimal(18,2)）需要明确指定总位数（precision）和小数位数（scale）。EF Core 不会自动猜——不配就用默认值（通常是
decimal(18,2)或
decimal(18,0)，取决于提供程序），但很多场景下这不够用。 用 Fluent API 配置单个属性：
modelBuilder.Entity<product>().Property(p => p.Price).HasColumnType("decimal(18,2)");</product>
EF Core 6+ 推荐全局统一配置：modelBuilder.Properties<decimal>().HavePrecision(18, 2);</decimal>若需差异化（比如金额用 2 位，利率用 6 位），可用自定义特性 +
ConfigureConventions或在
OnModelCreating中遍历筛选属性类型后设置
double/float 默认按数据库原生浮点类型映射
double映射为
float(53)（SQL Server）、
REAL或
DOUBLE PRECISION（PostgreSQL），
float通常映射为
real。它们本身就不保证精度，EF Core 不做额外精度控制 —— 这是设计使然，不是 bug。 不需要、也不应给
double设
HavePrecision，EF Core 会忽略该配置 如果业务真需要高精度计算（比如科学建模），建议改用
decimal并配好精度，而非强求
double精确 SQLite 是个特例：它没有真正的
decimal，所有数值都存为浮点，所以
decimal属性在 SQLite 上本质是模拟的，读写都可能有隐式转换和舍入
避免混用 decimal 和 double 导致的隐式转换问题
在 LINQ 查询中混用两者（比如
where p.Price == someDoubleValue），EF Core 可能生成带 CAST 或 CONVERT 的 SQL，既影响性能，又可能因数据库端转换规则不同而结果异常。 保持查询参数类型与实体属性一致：
decimal字段就传
decimal参数，别用
double或
int直接比较 警惕 EF Core 自动装箱：比如
.Where(x => x.Price >= 99.9)中的
99.9是
double，应写成
99.9m（
decimal字面量） 用数据库函数时（如自定义标量函数），确保入参类型与函数声明严格匹配，否则可能触发意外转换
特殊提供程序要注意的细节
不同数据库对数值类型的实现差异直接影响映射行为：
SQL Server：支持完整decimal(p,s)，推荐优先使用 PostgreSQL：
numeric等价于
decimal，配置方式相同 MySQL：用
decimal或
fixed，注意版本对精度上限的支持（如旧版 max 为 65） SQLite：无原生 decimal，所有数值以 64 位浮点存储，
decimal属性只是“语义提示”，实际精度由 .NET 层模拟，不适合金融级精确计算
基本上就这些。关键不是“能不能映射”，而是“要不要精确”——选对类型、配对精度、避开隐式转换，比调任何高级技巧都管用。
