自定义仅支持正数的udecimal结构体是否为糟糕方案？

有没有现成的实现库？ #

有不少现成方案可以直接复用，不需要从零实现Decimal的复杂逻辑：

• 一些领域驱动设计（DDD）相关的开源库中提供了NonNegativeDecimal或PositiveDecimal这类包装器类型，它们通过封装原生decimal实现非负约束，内部已处理好校验和运算逻辑，稳定性有保障。
• 部分数值约束类库也包含这类类型，核心思路都是包装原生decimal而非重写底层逻辑，避免了自己实现Decimal带来的各种坑。

从零实现自定义Decimal结构体的不合理之处 #

直接复刻Decimal.cs的逻辑并修改为非负约束，存在诸多问题：

• 底层逻辑复杂度极高：.NET的decimal内部由96位整数、缩放因子和符号位构成，涉及大量边界运算（如四舍五入、精度处理、溢出判断），自己实现很容易在极端场景下出现精度丢失、运算错误等隐蔽bug，且排查难度极大。
• 兼容性差：自定义结构体无法与原生decimal无缝兼容，和现有代码交互需要频繁显式转换；同时.NET内置的数学方法、LINQ等工具只支持原生decimal，自定义类型无法直接使用，需要额外编写大量扩展方法。
• 维护成本高：后续.NET版本对decimal的优化（如性能提升、新特性），自定义类型无法同步受益，需要持续跟进维护，长期来看性价比极低。

更合理的替代方案 #

1. 包装器模式（推荐） #

创建一个封装原生decimal的结构体，在构造、运算时校验非负约束，示例代码如下：

public readonly struct NonNegativeDecimal : IEquatable<NonNegativeDecimal>, IComparable<NonNegativeDecimal>
{
    public decimal Value { get; }

    public NonNegativeDecimal(decimal value)
    {
        if (value < 0)
            throw new ArgumentOutOfRangeException(nameof(value), "值不能为负数");
        Value = value;
    }

    // 显式转换：decimal → NonNegativeDecimal（强制校验）
    public static explicit operator NonNegativeDecimal(decimal value)
        => new NonNegativeDecimal(value);

    // 隐式转换：NonNegativeDecimal → decimal（安全转换）
    public static implicit operator decimal(NonNegativeDecimal nonNegative)
        => nonNegative.Value;

    // 加法运算：结果自动校验非负
    public static NonNegativeDecimal operator +(NonNegativeDecimal a, NonNegativeDecimal b)
        => new NonNegativeDecimal(a.Value + b.Value);

    // 减法运算：需确保结果非负，否则抛出异常
    public static NonNegativeDecimal operator -(NonNegativeDecimal a, NonNegativeDecimal b)
    {
        var result = a.Value - b.Value;
        if (result < 0)
            throw new InvalidOperationException("减法结果不能为负数");
        return new NonNegativeDecimal(result);
    }

    // 实现相等性与比较接口
    public bool Equals(NonNegativeDecimal other) => Value.Equals(other.Value);
    public int CompareTo(NonNegativeDecimal other) => Value.CompareTo(other.Value);
    public override bool Equals(object obj) => obj is NonNegativeDecimal other && Equals(other);
    public override int GetHashCode() => Value.GetHashCode();
}

这种方式只需要处理约束校验和必要的运算封装，复用原生decimal的全部底层逻辑，既安全又易维护。

2. 编译期校验工具 #

如果不想引入自定义类型，可以使用Roslyn分析器或代码分析规则，通过标记自定义[NonNegative]属性，在编译阶段强制检查decimal参数/字段是否满足非负要求，提前发现问题，避免运行时重复校验的繁琐。

内容的提问来源于stack exchange，提问作者Sean