c# 标准库中不存在 igenericnumber 接口，真正可用的是 .net 6+ 引入的静态抽象接口如 inumber、iaddition 等，用于编写类型安全且可被 jit 优化的泛型数值算法。
IGenericNumber 不存在，别被名字骗了
C# 标准库中根本没有 IGenericNumber<t></t> 这个接口——它不是 .NET 的一部分，也不是 C# 语言内置的泛型数学支持。你看到这个名字，大概率是混淆了早期提案、第三方库（比如 System.Numerics.IAddition 等新接口），或者误读了某些博客/教程的虚构示例。
真正可用的是从 .NET 6 开始引入的一组“静态抽象接口”（static abstract interface members），比如：
IAddition<tself tother tresult></tself>IMultiply<tleft tright tresult></tleft>IComparisonOperators<tself tother tresult></tself>-
INumber<tself></tself>（最常用，覆盖加减乘除、零值、一值等）
用 INumber 写通用数学算法（.NET 6+）
要写真正可泛型、类型安全、且能被 JIT 优化的数值算法，必须依赖 INumber<t></t> 及其派生接口。它要求实现类型（如 int、double、decimal、BigInteger）提供统一的数学契约。
一个典型例子：计算数组平均值
public static T Average<T>(T[] values) where T : INumber<T>
{
if (values.Length == 0) throw new ArgumentException("Array cannot be empty");
T sum = T.Zero;
foreach (T value in values)
{
sum = sum + value; // ✅ 编译通过：+ 被 INumber<T> 约束保证
}
return sum / T.CreateChecked(values.Length); // ✅ T.CreateChecked 允许 int→T 安全转换
}注意：T.CreateChecked 比 T.CreateSaturating 或 T.CreateTruncating 更严格，失败时抛异常，适合明确需要精确性的场景。
常见编译错误和绕过方式
即使加了 where T : INumber<t></t>，仍可能报错，典型原因如下：
-
Operator '+' cannot be applied to operands of type 'T' and 'T'→ 忘记约束或用了旧 SDK（需 .NET 6+ 和 C# 11+ 语言版本） -
'T' must be a non-nullable value type→ 错误地加了struct约束；INumber<t></t>本身已隐含非空值类型要求，额外加struct会冲突 - 想用
Math.Sqrt或Math.Log→ 这些不在INumber<t></t>中；需额外约束IFloatingPoint<t></t>（适用于float、double、Half） - 对
decimal使用IFloatingPoint<t></t>→ 不行，decimal不实现该接口；得单独处理或用运行时分支
性能与兼容性现实提醒
泛型数学接口在编译期做约束检查，运行时调用的是静态方法（本质是虚调用的替代），性能接近手写特化代码，但仍有微小开销。实际影响通常可忽略，除非在 tight loop 中每秒调用百万次以上。
关键限制：
- 不支持自定义数值类型（如你的
MyFixedPoint）——除非你显式实现全部 20+ 个静态抽象成员，工程量极大 - .NET Framework / .NET 5- 不支持；最低要求 .NET 6（LTS）及以上
- Unity 用户注意：Burst 编译器目前不识别这些接口，IL2CPP 也存在兼容性风险，生产项目慎用
最易被忽略的一点：这些接口只解决“运算符重载”的泛型问题，不解决“精度控制”“舍入模式”“NaN 传播规则”等深层数值语义——那些还得靠具体类型自己保证，泛型层无法干预。
