结论：金融等需精确十进制运算的场景必须用decimal，科学计算等可容忍误差且需高性能的场景才用double；0.1+0.2≠0.3是ieee 754二进制浮点固有缺陷，decimal以十进制存储可完全避免该问题。
直接说结论：金融、金额、配置值、用户输入的带小数字符串转数值等场景，一律用 decimal；科学计算、物理模拟、图形渲染等对绝对精度不敏感但要求大范围或高速运算的场景，才考虑 double。用错类型是精度问题的根源，不是靠 Math.Round 能“修好”的。
为什么 0.1 + 0.2 != 0.3 在 C# 里真实发生
这不是 C# 的 bug，是 IEEE 754 二进制浮点标准的固有缺陷。double 和 float 都无法精确表示十进制小数 0.1、0.2、0.3……它们在内存中存储的是近似值：
-
0.1d实际存的是0.1000000000000000055511151231257827021181583404541015625 -
0.1m（decimal）能 100% 精确表示为十进制的 0.1，因为它是按“十进制位”而非“二进制位”存储的 - 这种误差在加减乘除中会累积，尤其乘以 100、转
byte或int时极易触发截断错误（比如(byte)(1.14 * 100)得到 113 而非 114）
decimal 和 double 的关键差异不能只看“位数”
光记“decimal 是 128 位，double 是 64 位”没用，得看它怎么用：
-
double：符号 1 位 + 指数 11 位 + 尾数 52 位 → 支持极大/极小范围（±1.7×10³⁰⁸），但十进制有效位只有约 15–16 位；所有运算都在二进制下进行，天然存在舍入 -
decimal：96 位整数部分 + 1 位符号 + 5 位缩放因子（scale）→ 十进制精度固定 28–29 位；所有运算模拟手算十进制逻辑，无二进制舍入误差；但范围小得多（±7.9×10²⁸），且不支持NaN、Infinity - 性能上：
double运算由 CPU 硬件加速，decimal是软件实现，基础四则慢 10–30 倍；但对业务系统而言，这点开销远小于一次数据库 round trip
JSON 反序列化时 decimal 必须显式声明
很多人把 JSON 字段反序列化成 double 或 float，结果 0.4064 变成 0.40639999999999997——这不是解析器的问题，是你没告诉它“这该是十进制数”：
- 用
System.Text.Json：字段类型必须声明为decimal，且确保JsonSerializerOptions.NumberHandling不强制转 float/double - 用
Newtonsoft.Json：同样要写public decimal Amount { get; set; }；若原始 JSON 是字符串形式（如"0.4064"），它会自动转decimal；但如果是数字字面量（0.4064），仍可能被底层读取器当作 double 解析 - 极端情况可退一步：用
string接收再手动decimal.TryParse，但这是兜底方案，不该是默认选择
别依赖 Math.Round “掩盖” double 的误差
Math.Round(value * 100, 0) 看似能修好 113.99999999999999，但它只是把问题藏得更深：
- 误差仍在：你 Round 后得到 114.0，但这个 114.0 是
double类型，它本身可能仍是近似值（比如 114.00000000000001） - 边界 case 更危险：当真实值是 113.49999999999999，Round 到整数得 113；但如果是 113.50000000000001，就得 114 —— 你根本控制不了中间那个“临界点”在哪
- 真正安全的做法是：从源头就用
decimal，例如decimal.Parse("1.14") * 100直接得114.00m，再转int或byte也毫无风险
最常被忽略的一点：decimal 字面量必须带后缀 m（如 1.14m），否则 C# 默认按 double 解析——哪怕你把它赋给 decimal 变量，转换动作已在编译期发生，精度早已丢失。
