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对除零或溢出的处理仍依赖底层类型逻辑，不会自动抛出统一异常。
