INumber 是 .NET 7+ 引入的泛型数值接口，需显式调用 T.Add(a,b) 等静态方法，不支持 a+b 运算符；必须约束为 where T : INumber，且仅限已实现该接口的具体类型。
INumber 是 .NET 7+ 才有的泛型数值接口，不是“所有数值类型都默认实现”的万能契约
很多人看到 INumber<t></t> 就以为能直接写 public T Add<t>(T a, T b) where T : INumber<t></t></t> 然后传入 int、double、decimal 都行——但实际会编译失败。原因在于：C# 编译器目前（截至 .NET 8）**不支持对 INumber<t></t> 做算术运算符重载的静态抽象调用**。你不能直接写 a + b，哪怕 T 满足 INumber<t></t> 约束。
真正能用的，是它定义的一组静态方法（如 Add、Multiply、Zero），且这些方法必须通过 T 的静态虚成员（static abstract members）机制调用——而调用方式受限于语言特性。
- 必须用
T.Add(a, b)，不能用a + b -
T必须是“已知实现了INumber<t></t>”的具体类型，比如int、long、float；但不能是未约束的泛型参数（如U），除非你也给U加上INumber<u></u>约束 - .NET 7+ 运行时才提供这些接口实现，.NET 6 及更早版本没有
INumber<t></t>
正确写法：用静态抽象成员 + 泛型约束 + 显式调用静态方法
要写一个通用加法函数，得这样写：
public static T Add<T>(T a, T b) where T : INumber<T>
{
return T.Add(a, b);
}注意三点：
-
where T : INumber<t></t>是必须的，否则无法访问T.Add - 必须显式调用
T.Add(a, b)，而不是a + b（后者在泛型上下文中不被允许） - 调用时传入的类型必须真实实现
INumber<t></t>：比如Add<int>(1, 2)</int>可以，但Add<mycustomtype>(x, y)</mycustomtype>不行，除非你手动为MyCustomType实现了INumber<mycustomtype></mycustomtype>
类似地，获取零值、比较、解析字符串等操作也得走对应静态方法：T.Zero、T.LessThan(a, b)、T.Parse("123", null)。
常见错误：试图绕过约束或混用旧式泛型
以下写法都会报错：
-
public T Sum<t>(IEnumerable<t> values) where T : struct</t></t>——struct约束太宽，T.Add不可用 -
public T Sum<t>(IEnumerable<t> values) where T : INumber<t></t></t></t>但内部写sum += item—— 编译器拒绝，因为+=不被泛型解析 - 把
INumber<t></t>和IConvertible或IComparable混用 —— 它们语义不同，INumber<t></t>关注算术能力，不是类型转换
性能上，INumber<t></t> 调用是 JIT 内联友好的，和直接写 int.Add 几乎无开销；但如果你用反射或 dynamic 去“模拟”，就完全失去泛型优势了。
替代方案：当 INumber 不适用时，考虑 NumericVector 或第三方库
如果需要更高阶的数值操作（如向量加法、矩阵乘法、复数/有理数支持），INumber<t></t> 本身不提供这些。此时可考虑：
-
NumericVector<t></t>（来自System.Numerics扩展包，非官方，需 NuGet 引入） - 使用
MathF/Math的泛型适配包装（例如封装Sqrt、Abs） - 接受具体类型重载（如
Sum(int[])、Sum(double[])），比泛型更稳定、更易调试
最常被忽略的一点是：**INumber<t></t> 不包含浮点精度控制、舍入模式、NaN/Infinity 行为约定**。做金融计算时，decimal 虽然实现了它，但 T.Divide 对除零或溢出的处理仍依赖底层类型逻辑，不会自动抛出统一异常。
