C# 数值接口INumber方法 C#如何编写通用的数值算法

INumber 是 .net 7+ 引入的泛型数值接口，需显式调用 T.Add(a,b) 等静态方法，不支持 a+b 运算符；必须约束为 where T : INumber，且仅限已实现该接口的具体类型。

c#如何编写通用的数值算法”>

INumber 是 .NET 7+ 才有的泛型数值接口，不是“所有数值类型都默认实现”的万能契约

很多人看到 INumber 就以为能直接写 public T Add(T a, T b) where T : INumber 然后传入 int、double、decimal 都行——但实际会编译失败。原因在于：C# 编译器目前（截至 .NET 8）**不支持对 INumber 做算术运算符重载的静态抽象调用**。你不能直接写 a + b，哪怕 T 满足 INumber 约束。

真正能用的，是它定义的一组静态方法（如 Add、Multiply、Zero），且这些方法必须通过 T 的静态虚成员（Static abstract members）机制调用——而调用方式受限于语言特性。

• 必须用 T.Add(a, b)，不能用 a + b
• T 必须是“已知实现了 INumber”的具体类型，比如 int、long、Float；但不能是未约束的泛型参数（如 U），除非你也给 U 加上 INumber 约束
• .NET 7+ 运行时才提供这些接口实现，.NET 6 及更早版本没有 INumber

正确写法：用静态抽象成员 + 泛型约束 + 显式调用静态方法

要写一个通用加法函数，得这样写：

public static T Add(T a, T b) where T : INumber {     return T.Add(a, b); }

注意三点：

• where T : INumber 是必须的，否则无法访问 T.Add
• 必须显式调用 T.Add(a, b)，而不是 a + b（后者在泛型上下文中不被允许）
• 调用时传入的类型必须真实实现 INumber：比如 Add(1, 2) 可以，但 Add(x, y) 不行，除非你手动为 MyCustomType 实现了 INumber

类似地，获取零值、比较、解析字符串等操作也得走对应静态方法：T.Zero、T.LessThan(a, b)、T.Parse("123", NULL)。

常见错误：试图绕过约束或混用旧式泛型

以下写法都会报错：

• public T Sum(IEnumerable values) where T : Struct —— struct 约束太宽，T.Add 不可用
• public T Sum(IEnumerable values) where T : INumber 但内部写 sum += item —— 编译器拒绝，因为 += 不被泛型解析
• 把 INumber 和 IConvertible 或 IComparable 混用 —— 它们语义不同，INumber 关注算术能力，不是类型转换

性能上，INumber 调用是 JIT 内联友好的，和直接写 int.Add 几乎无开销；但如果你用反射或 dynamic 去“模拟”，就完全失去泛型优势了。

替代方案：当 INumber 不适用时，考虑 NumericVector 或第三方库

如果需要更高阶的数值操作（如向量加法、矩阵乘法、复数/有理数支持），INumber 本身不提供这些。此时可考虑：

• NumericVector（来自 System.Numerics 扩展包，非官方，需 NuGet 引入）
• 使用 mathF/Math 的泛型适配包装（例如封装 Sqrt、Abs）
• 接受具体类型重载（如 Sum(int[])、Sum(double[])），比泛型更稳定、更易调试

最常被忽略的一点是：**INumber 不包含浮点精度控制、舍入模式、NaN/Infinity 行为约定**。做金融计算时，decimal 虽然实现了它，但 T.Divide 对除零或溢出的处理仍依赖底层类型逻辑，不会自动抛出统一异常。