inumber 是需类型完整实现的静态契约，非仅加约束即可使用；常见失效原因包括 sdk 版本不足、语言版本未设为 c# 11+、class 类型不支持、缺失必要静态成员、bcl 类型实现不全、crtp 自引用错误，以及误用 math 而非类型静态方法。
INumberT.Zero、+、T.CreateChecked 全部失效。
为什么加了 where T : INumber<t></t> 还报 CS0019 “operator + cannot be applied”
这不是语法写错了，而是编译器根本没把你的类型识别为合法的 INumber<t></t> 实现者。常见原因有：
- .NET SDK 版本低于 6.0，或项目语言版本未设为 C# 11+（需在
.csproj中显式指定<langversion>11</langversion>） - 类型是 class 而非 struct ——
INumber<t></t>要求非空值类型，class 无法满足底层静态抽象成员绑定要求 - 类型实现了
INumber<mytype></mytype>，但没提供所有必需的静态抽象成员：至少包括Zero、One、operator +、operator -、CreateChecked，缺一不可 - 泛型方法里写了
where T : INumber<t></t>，但调用时传入的是int或double等 BCL 类型——它们在 .NET 7+ 才完整实现INumber<t></t>，若目标框架是 .NET 6，int只实现部分接口（如IAdditionOperators），不满足完整约束
INumber<t></t> 的实现必须带 CRTP 自引用，不能偷懒写成 IParsable<dateonly></dateonly>
你定义一个 MyDate 类型并想让它支持泛型解析，不能写成 IParsable<dateonly></dateonly>。因为 IParsable<tself></tself> 的静态方法（如 Parse）是通过 TSelf 类型本身来解析的，编译器需要知道“谁在实现它”。
错误写法：public struct MyDate : IParsable<dateonly></dateonly> → 编译器认为“MyDate 在帮 DateOnly 实现”，但 MyDate.Parse(...) 根本不存在，调用即报 CS0315。
正确写法必须自引用：
public readonly struct MyDate : IParsable<mydate>
{
public static MyDate Parse(string s, IFormatProvider? provider) => ...;
public static bool TryParse(string? s, IFormatProvider? provider, out MyDate result) => ...;
}</mydate>
同理，INumber<mydate></mydate>、IBinaryInteger<mydate></mydate> 全部遵循这个规则：接口里的 TSelf 参数必须填你自己的类型名，不能替换、不能省略、不能用基类。
用 INumber<t></t> 写通用算法时，别直接依赖 Math.Sqrt 或 Math.Log
INumber<t></t> 本身不提供开方、对数、三角函数等——这些属于浮点专属能力，得升级约束到 IFloatingPoint<t></t> 或更细粒度的 IFloatingPointIeee754<t></t>。
所以这段代码会编译失败：
public static T SqrtSum<t>(T[] values) where T : INumber<t>
{
T sum = T.Zero;
foreach (T v in values) sum += v;
return Math.Sqrt(sum); // ❌ Math.Sqrt 没泛型重载，且 T 不一定是 float/double
}</t></t>
正确做法是分层约束：
- 整数场景：用
IBinaryInteger<t></t>+IShiftOperators手写整数平方根（或放弃） - 浮点场景：改约束为
where T : IFloatingPoint<t></t>，然后用T.Sqrt(sum)（注意是类型上的静态方法，不是Math.Sqrt） - 混合场景：用运行时分支，或引入
dynamic（不推荐，丢掉类型安全）
另外注意：decimal 不实现 IFloatingPoint<t></t>，哪怕它能表示小数——它的数学行为不符合 IEEE-754，所以所有 Sqrt/Log 都不可用，必须单独处理。
泛型数学性能不错，但别误以为它能替代所有数值抽象
JIT 对 INumber<t></t> 静态抽象调用做了专门优化，实测接近手写专用代码，这点不用怀疑。但容易被忽略的是：它只解决“编译期可验证的运算契约”，不解决“运行时动态数值行为差异”。
比如：
-
int溢出默认回绕，checked块才抛异常；而BigInteger从不溢出；Half极易下溢为 0 —— 这些语义差异不会被INumber<t></t>约束捕获 -
T.CreateChecked(1000)对byte抛异常，对int成功，对BigInteger总是成功 —— 你得自己决定要不要吞异常或 fallback - 没有统一的“精度控制”或“舍入模式”抽象，
decimal.Round和double.Round参数不同，无法用同一泛型签名覆盖
换句话说：泛型数学帮你跨类型写加减乘除，但跨类型的“数值哲学”（溢出策略、精度边界、特殊值处理）还得你自己兜底。
