C#的运算符重载是个很容易被当成“花活”的特性。刚入行时我也觉得这玩意儿就是给自定义类型加上数学符号写出来像在炫耀语法。直到后来做上位机数据采集、做科学计算库、做表达式树封装才发现运算符重载真正解决的问题是让业务代码从“一长串方法调用”变成“一眼能看出意图的算式”。这篇不讲那些教科书里背一遍就忘的抽象理论就说说我这些年实际用下来的理解它到底为谁而生、语法上有哪些必须守死的规矩、哪些坑是文档不会告诉你的以及几个可以直接拿去改的完整案例。1. 运算符重载到底为谁而生值语义类型与“让代码像数学”的设计动机1.1 为什么C#不允许直接给自定义类型用加号C#是强类型语言、-、*、/这些运算符对编译器来说本质上是“某个类型上的特定方法”。内置的 int、double 能用是因为 CTS 里这些类型已经定义好了加法行为。你自定义一个Complex、Vector2、TorqueSample编译器根本不知道两个这样的对象“相加”是什么意思——是合并数据是逐元素相加还是把两个读数做累计所以默认状态下自定义类型使用运算符是编译错误。运算符重载就是给类型补上这一段“资质证明”你告诉编译器当这个类型出现在两侧时调用我写的这个静态方法。它不是什么黑魔法就是一个经过语法糖包装的静态方法调用。这一点先记牢后面讲反编译、讲泛型约束都用得上。1.2 适合重载的场景与不该重载的“陷阱场景”根据我的经验适合做运算符重载的类型几乎都有一个共同特征值语义也就是这个类型的实例表示“一个数值/一段数据本身”而不是“对某个对象的引用”。典型例子数学类型复数、向量、矩阵、四元数。单位类型长度、温度、扭矩、速度数值本身带上单位。业务值对象金额、百分比、评分这些对象之间的加减乘除有明确的业务含义。小范围的 DSLSQL 条件表达式、断言构建器、状态转移比较器。不适合重载的场景也值得说清楚。如果你的类型是个引用类型比如一个Order、一个User你非要给它重载表示“合并订单”这就很危险。读者看到orderA orderB第一反应是“这俩订单还能加”然后要去翻代码才能知道你所谓的“加”是合并商品列表还是合并金额。这种非直觉语义会在 code review 和后续维护里反复消耗团队精力。同理如果一个运算符重载的实现需要“偷偷改掉对象内部状态”也基本可以判定为设计错误——运算符重载应当是无副作用的纯计算输入两个值返回一个新值完事。我还有一个习惯性判断标准如果一个操作你很难用一句话说清语义那就不该重载。a b如果不能用“把两者的值相加/合并并返回新值”这句人话解释清楚就别碰。2. 写重载前的必修课签名约束、成对规则与编译器映射2.1 五种签名规则违反一条就编译不过运算符重载的声明格式很固定所有重载方法都必须是public static而且必须含参数。不要问我为什么不能是实例方法——运算符是二元不对称运算编译器解析left right时需要考虑两个操作数的类型实例方法天然没法表达这种“左右开弓”的对称性。签名上有五条硬规矩方法名必须是operator 符号比如operator 、operator 注意符号和 operator 之间有空格。参数列表至少要有一个参数的类型是“声明该运算符的所在类型”。比如你在Complex里写operator 两个参数可以都是Complex也可以一个是Complex一个是double但绝不能两边都没有Complex。二元运算符要有两个参数一元运算符要有一个参数。不能使用ref、out、in修饰参数C# 7.2 后可以用in但没必要。返回类型大多数情况下可以随意但比较运算符 ! 以及true/false运算符必须返回bool。举个例子下面这种跨类型加法是合法的public readonly struct Length { private readonly double _meters; public Length(double meters) _meters meters; public static Length operator (Length left, Length right) new Length(left._meters right._meters); public static Length operator *(Length left, double scale) new Length(left._meters * scale); // return 类型不非得是所在类型 public static double operator /(Length left, Length right) left._meters / right._meters; }Length * double很直观Length / Length返回一个无量纲的double也很自然——比率本来就是没有单位的。这个“返回类型可以不同于参数类型”的灵活性在单位换算场景里非常实用。2.2 哪些能重载、哪些不能以及成对出现的硬性要求网上很多表格又把简单事情搞复杂了。我按自己的记忆方式整理给你可以直接重载的运算符类别运算符一元算术/逻辑、-、!、~、、--、true、false二元算术、-、*、/、%位运算、|、^、、比较运算符、!、、、、转换运算符implicit、explicit不能直接重载的成员访问符.、方法调用()、索引[]赋值号以及所有复合赋值符、-、*、/等条件逻辑运算符、||空合并符??类型信息相关typeof、sizeof、new、default、nameof其他?:、、is、as、await、-这里有两个容易误会的点。第一不能重载但如果你重载了a b会自动可用因为编译器会把它改写为a a b。这个“免费赠送”很有用但它也意味着你的类型必须支持“用加法结果整体替换原值”所以可变结构体配合运算符重载的坑会在这时候显现后面翻车现场那节细说。第二和||不能直接重载但当你同时重载了true、false和或|时编译器会在特定条件下允许你写a b。这个机制很适合做条件 DSL第 5 章我会给一个实际例子。还有一个比较隐蔽的硬性要求部分运算符必须成对出现。成对组合与!与与true与false你重载了却不重载!编译器直接报 CS0216 之类的错误要求同时定义匹配运算符。这个规矩不是刁难而是逻辑对称性如果 A 等于 B 有定义那 A 不等于 B 必须是你定义的反面编译器不允许你只做一半。同理小于和大于本来就是互斥关系。2.3 反编译视角运算符重载其实是一组静态方法我想强调一下前面提过的观点因为它能帮你理解很多“奇怪现象”。运算符重载在编译成 IL 之后就是一个普通静态方法名字是系统规定的映射。比如operator 对应op_Additionoperator 对应op_Equalityoperator true对应op_True。你用 dnSpy 或 ILSpy 反编译一个第三方库看到op_Addition这样的方法名就知道这个类型重载了加法运算符。这个事实带来的推论很重要运算符重载是编译期绑定不走虚方法分派。也就是说left right里left和right的编译期类型决定了调用哪个重载而不是运行期实际类型。如果你在一个基类里重载了运算符子类实例参与运算时编译器看的可能还是基类的重载版本。所以运算符重载和多态基本是水火不容的。既然是静态方法调用JIT 对简单实现通常可以做内联优化性能不会差到什么地步。你不需要为了“性能”刻意避开运算符重载但也不要在热路径里把重载方法写成一坨复杂的模板代码那就得不偿失了。因为它是个“方法”你可以用方法组的形式引用。比如Complex.op_Addition(a, b)这类直接调用虽然不推荐但在反射、表达式树编译等场景里你是可以“看到”它的。3. 两个能直接抄的完整案例复数类与上位机读数结构体3.1 复数覆盖加减乘除、比较、转换的完整写法复数是最经典的运算符重载教学案例因为它包含了几乎所有运算符类型四则运算、等于判断、隐式转换、比较虽然没有自然序但至少等于要有。下面这个版本我按生产环境的习惯写了readonly struct、实现IEquatableT、同步重写Equals和GetHashCode。public readonly struct Complex : IEquatableComplex { public double Real { get; } public double Imaginary { get; } public Complex(double real, double imaginary) { Real real; Imaginary imaginary; } public static Complex operator (Complex left, Complex right) new Complex(left.Real right.Real, left.Imaginary right.Imaginary); public static Complex operator -(Complex left, Complex right) new Complex(left.Real - right.Real, left.Imaginary - right.Imaginary); public static Complex operator *(Complex left, Complex right) new Complex( left.Real * right.Real - left.Imaginary * right.Imaginary, left.Real * right.Imaginary left.Imaginary * right.Real); public static Complex operator /(Complex left, Complex right) { double denominator right.Real * right.Real right.Imaginary * right.Imaginary; if (denominator 0) throw new DivideByZeroException(复数除法除数为零); return new Complex( (left.Real * right.Real left.Imaginary * right.Imaginary) / denominator, (left.Imaginary * right.Real - left.Real * right.Imaginary) / denominator); } public static bool operator (Complex left, Complex right) left.Equals(right); public static bool operator !(Complex left, Complex right) !left.Equals(right); public override bool Equals(object? obj) obj is Complex other Equals(other); public bool Equals(Complex other) Real.Equals(other.Real) Imaginary.Equals(other.Imaginary); public override int GetHashCode() HashCode.Combine(Real, Imaginary); public static implicit operator Complex(double value) new Complex(value, 0); public override string ToString() ${Real} {Imaginary}i; }几个容易被新手忽略的细节我都写在了这个例子里operator 内部直接调用Equals这是一个经验做法。如果你在里手工写“逐字段比较”容易和Equals的实现出现偏差导致同一个类型在不同比较路径下行为不一致。让和Equals共用一套逻辑是最保险的做法。IEquatableComplex加上Equals(Complex other)这个强类型重载是为了让ListComplex、Dictionary、LINQ 的Contains、Distinct在比较时走强类型路径避免装箱和反射。implicit operator Complex(double value)意味着double可以直接赋给ComplexComplex c 3.14;合法。但反过来说Complex不能隐式转double因为复数的实部虚部取出哪个语义不清所以就算要做也应该用explicit。3.2 上位机读数场景批量累加、均值与阈值判断觉得复数太“数学”那就看一个工程场景。我做上位机采集时经常要处理一批传感器读数先把每一帧的数据加起来算平均再判断有没有超过安全阈值。如果没有运算符重载代码会写成total.Value sample.Value; total.Count;一旦逻辑多了满屏都是.Value。我定义一个TorqueSample结构体把“累加值 次数”封装成一个整体。加法运算符负责合并两组读数除法和阈值比较也一并封装进去public readonly struct TorqueSample { public double Value { get; } public int Count { get; } public TorqueSample(double value, int count 1) { Value value; Count count; } public double Average Count 0 ? 0 : Value / Count; public static TorqueSample operator (TorqueSample left, TorqueSample right) new TorqueSample(left.Value right.Value, left.Count right.Count); public static double operator /(TorqueSample sample, int divisor) sample.Average / divisor; public static bool operator (TorqueSample sample, double threshold) sample.Average threshold; public static bool operator (TorqueSample sample, double threshold) sample.Average threshold; public static bool operator (TorqueSample sample, double threshold) sample.Average threshold; public static bool operator (TorqueSample sample, double threshold) sample.Average threshold; }调用方的代码就变得非常接近业务口语TorqueSample total new TorqueSample(0, 0); foreach (var frame in frames) { total frame; } double avg total.Average; if (total 5000) { Log.Warning(扭矩均值超限当前均值 {Avg}, avg); }拆开看total frame能工作靠的正是“重载后复合赋值自动可用”的规则。total 5000看起来是拿样本和数字比较实际走的是operator (TorqueSample, double)。代码读起来像业务描述这就是运算符重载的意义。3.3 案例背后的设计取舍这两个案例看着简单其实背后藏着几条设计取舍值得展开说为什么用readonly struct而不是class因为运算符重载返回“新对象”的语义和不可变类型天然契合。你写a b得到的应该是一个全新的值而不是把 a 或者 b 改掉。readonly强制了这种不可变性从设计层面避免写出“副作用型运算符”。为什么阈值判断不直接写sample.Average 5000因为平均值的计算逻辑被封装了。调用方不需要关心TorqueSample内部是用 Value 还是 Count 算平均值只需要表达意图“这个读数是否超限”。这是“封装”在运算符层面的体现。为什么比较运算符只和double做比较不做TorqueSample和TorqueSample的比较因为两个平均值的比较意义不大业务上更常见的是“读数值 vs 阈值”。重载时不贪多只重载你真正需要的这是我反复强调的原则。4. 翻车现场盘点与Equals分裂、隐式转换泛滥、结构体可变性4.1 重载了却忘记同步Equals和GetHashCode字典.Contains的诡异表现这个坑我见过太多次了。你高高兴兴地重载了operator 然后写ListMyType.Contains(item)结果发现它根本不走你的判断结果和自己预期的完全不一样。原因在于很多 API 在比较时用的是EqualityComparerT.Default而不是。ListT.Contains、HashSetT、DictionaryTKey,TValue、LINQ 的Distinct/Contains/Except默认走的是EqualityComparerT.Default。这个默认实现的选择顺序大致是如果类型实现了IEquatableT走IEquatableT.Equals否则走object.Equals。operator 反而不在默认比较器的主要路径里。所以只重载而不实现IEquatableT、不重写Equals你会得到一套“分裂”的行为写a b时走你重载的逻辑写list.Contains(a)时走默认的相等逻辑对 struct 可能是逐字段反射比较对 class 可能是引用比较。这俩结果不一致排查起来极其痛苦。我的做法是形成一个固定四件套每次定义值类型都照抄public static bool operator (MyType left, MyType right) left.Equals(right); public static bool operator !(MyType left, MyType right) !left.Equals(right); public override bool Equals(object? obj) obj is MyType other Equals(other); public override int GetHashCode() /* 用成员算哈希 */;如果类型实现IEquatableT再加一个public bool Equals(MyType other)。这样、Equals完全同源GetHashCode基于同样的成员计算字典、集合、LINQ 全部行为一致。4.2 隐式转换泛滥方法重载决议瞬间变得不可预测implicit运算符很诱人因为它能让代码“顺滑”。比如Complex c 3.14;写起来多舒服。但滥用隐式转换会让编译器在重载决议时抓狂。想象一下你定义了一个Temperature类型给它加了隐式转换到double然后你的代码里某处重载了SomeMethod(Temperature)和SomeMethod(double)。调用SomeMethod(temp)时编译器会优先选Temperature版本这还算好。但如果调用SomeMethod(0)编译器就要想0是转成Temperature调第一个重载还是直接作为double调第二个重载可能不报错但语义已经变得脆弱。更麻烦的是一旦某些框架或第三方库也有大量重载隐式转换会让所有“看起来差不多”的类型互相乱窜编译错误和运行时误调用的概率飙升。我的经验是隐式转换只保留给“没有信息丢失且语义绝对清晰”的转换比如int到long、派生类到基类。自定义类型之间一律用explicit转换让调用方在用(Fahrenheit)tempC这类强转时明确知道这里有一层换算。实在想要“方便”可以提供一个ToDouble()之类的命名方法比隐式转换可读性高得多。4.3 可变结构体、连续比较与NULL判断的连环坑可变结构体 运算符重载是另一个经典组合坑。先看这段代码public struct Counter { public int Value; public static Counter operator (Counter left, Counter right) new Counter { Value left.Value right.Value }; } Counter c new Counter { Value 1 }; c new Counter { Value 2 };表面上c.Value变成 3没问题。但结构体是值类型c other实际是“先拷贝一份 c调用加法再把结果赋回 c”。如果Counter内部还有引用类型成员或者被放在数组、字典里这种拷贝替换会带来一些意想不到的“赋值后没生效”的感觉。所以一旦决定用结构体承载运算符重载最好直接声明readonly struct从一开始就断绝“改内部状态”的念头。还有a b c这种写法。很多人会把连续比较写成a b c以为是在数学课上写的“a 等于 b 等于 c”。在 C# 里这叫链式比较实际结果是(a b) c先得到一个bool再用这个bool去和 c 比较。bool和 c 的类型不同时编译器可能直接报错也可能因为你给 c 定义了隐式转换而“神奇”地通过编译——后者才是最可怕的因为运行时大概率不是你想要的语义。建议在团队规范里明确连续比较要写成a b b c。最后是 NULL 判断。给引用类型重载时最常见的翻车是在实现里直接访问成员而忘记判空public static bool operator (Person left, Person right) left.Age right.Age; // 这里 left 或 right 为 null 时直接 NullReferenceException重载后所有地方都会尝试走你这个方法包括person null。我见过有人为了修这个坑在实现里写了一堆ReferenceEquals(left, null)的防守代码结果和Equals的逻辑又冲突了。更干净的做法是要么干脆不要在引用类型上重载只在值类型上重载要么在里用left?.Equals(right) true这种安全调用模式并且把 null 判断逻辑和Equals保持一致。5. 进阶玩法checked溢出控制、true/false短路重载与用户定义转换5.1 checked/unchecked运算符让溢出不再静默如果你的自定义数值类型内部靠整数运算实现默认情况下整数溢出是静默发生的。这在做加密、校验、仪器数据累加时可能是致命的——某个中间结果悄悄回绕成负数后面所有计算都错。C# 从较新的语言版本开始支持为用户自定义运算符声明 checked 版本写法是在运算符前加checked关键字public readonly struct WrappingCounter { private readonly int _value; public WrappingCounter(int value) _value value; public static WrappingCounter operator (WrappingCounter left, WrappingCounter right) new WrappingCounter(left._value right._value); public static WrappingCounter operator checked (WrappingCounter left, WrappingCounter right) new WrappingCounter(checked(left._value right._value)); }这样在checked上下文中运行的代码比如项目里设置了/checked或者局部写了checked块会用 checked 版本溢出时抛OverflowException普通上下文里则用不带 checked 的版本保持原有回绕行为。这个特性在实现带校验的协议帧、计数器、哈希值时很有价值。5.2 true/false重载用写出可读的条件拼接和||不能直接重载但当你需要构建一个“条件对象”并且希望调用方用组合语义时true/false加上的配合就能派上用场。比如我做 SQL 拼接 DSL不引入一整棵表达式树的前提下定义了一个SqlConditionpublic readonly struct SqlCondition { public string Sql { get; } public object[] Parameters { get; } public SqlCondition(string sql, object[] parameters) { Sql sql; Parameters parameters; } public static bool operator true(SqlCondition condition) !string.IsNullOrEmpty(condition.Sql); public static bool operator false(SqlCondition condition) string.IsNullOrEmpty(condition.Sql); public static SqlCondition operator (SqlCondition left, SqlCondition right) { if (string.IsNullOrEmpty(left.Sql)) return right; if (string.IsNullOrEmpty(right.Sql)) return left; return new SqlCondition($({left.Sql}) AND ({right.Sql}), left.Parameters.Concat(right.Parameters).ToArray()); } }当编译器看到condA condB时会尝试翻译成先调用false(condA)如果 condA 已经是一个“空条件”false 为真整个表达式的结果就是 condA不再计算否则调用(condA, condB)。这样写出来的调用代码就是SqlCondition final filterByUser filterByDate filterByStatus;每一段条件可以单独维护组合逻辑却像自然语言。这种场景下true/false重载不是“提升性能”而是让 DSL 的短路求值语义成立。5.3 转换运算符与泛型约束的配合最后聊一个和“泛型”玩家息息相关的话题。经常有人问我能不能写一个泛型方法T AddT(T a, T b)约束为“支持运算符”答案是不行C# 的泛型约束里没有“必须有加法运算符”这种约束。你没法在泛型方法里直接写a b。常见的替代方案有两个。一是定义接口并约束public interface IAddableT { T Add(T other); } public static T SumAllT(IEnumerableT items) where T : IAddableT { T result default!; foreach (var item in items) result result.Add(item); return result; }类内部可以用运算符重载实现这个接口外部既能享受运算符的语法糖又能在泛型约束中“看到”加法能力。二是用表达式树在运行时动态编译加法表达式。这个方法灵活但复杂度和代价都不低一般用在规则引擎、计算引擎这类确实需要动态解析的地方普通业务代码没必要。我的建议是如果有明确的有限类型集合优先用接口约束如果类型完全未知且必须做任意数学运算再考虑表达式树。运算符重载本身就绑定在具体类型上想让它“泛化”成通用约束本身就是反着用这个特性。我在实际项目里还有个习惯每重载一组运算符就在注释里写清楚“这个运算符的业务语义是什么”。比如TorqueSample的注释我会写“合并两个采样周期累加值与次数同时相加”。这种注释不是啰嗦而是为了阻止下一个人误用。毕竟运算符重载让代码读起来像数学算式那是牺牲了“显式方法名”换来的清晰如果语义没说清这笔交易就亏了。运算符重载真正该用的场景永远是那几个科学计算、单位换算、值对象、DSL。它让代码从“调用方法的啰嗦”变成“表述业务的算式”这是它的价值。而它最大的代价就是容易让不了解设计意图的人误用。所以重载前先问自己一句这个符号读者能秒懂吗能就上不能就乖乖用命名方法吧。
C#的运算符重载是个很容易被当成“花活”的特性。刚入行时我也觉得这玩意儿就是给自定义类型加上数学符号写出来像在炫耀语法。直到后来做上位机数据采集、做科学计算库、做表达式树封装才发现运算符重载真正解决的问题是让业务代码从“一长串方法调用”变成“一眼能看出意图的算式”。这篇不讲那些教科书里背一遍就忘的抽象理论就说说我这些年实际用下来的理解它到底为谁而生、语法上有哪些必须守死的规矩、哪些坑是文档不会告诉你的以及几个可以直接拿去改的完整案例。1. 运算符重载到底为谁而生值语义类型与“让代码像数学”的设计动机1.1 为什么C#不允许直接给自定义类型用加号C#是强类型语言、-、*、/这些运算符对编译器来说本质上是“某个类型上的特定方法”。内置的 int、double 能用是因为 CTS 里这些类型已经定义好了加法行为。你自定义一个Complex、Vector2、TorqueSample编译器根本不知道两个这样的对象“相加”是什么意思——是合并数据是逐元素相加还是把两个读数做累计所以默认状态下自定义类型使用运算符是编译错误。运算符重载就是给类型补上这一段“资质证明”你告诉编译器当这个类型出现在两侧时调用我写的这个静态方法。它不是什么黑魔法就是一个经过语法糖包装的静态方法调用。这一点先记牢后面讲反编译、讲泛型约束都用得上。1.2 适合重载的场景与不该重载的“陷阱场景”根据我的经验适合做运算符重载的类型几乎都有一个共同特征值语义也就是这个类型的实例表示“一个数值/一段数据本身”而不是“对某个对象的引用”。典型例子数学类型复数、向量、矩阵、四元数。单位类型长度、温度、扭矩、速度数值本身带上单位。业务值对象金额、百分比、评分这些对象之间的加减乘除有明确的业务含义。小范围的 DSLSQL 条件表达式、断言构建器、状态转移比较器。不适合重载的场景也值得说清楚。如果你的类型是个引用类型比如一个Order、一个User你非要给它重载表示“合并订单”这就很危险。读者看到orderA orderB第一反应是“这俩订单还能加”然后要去翻代码才能知道你所谓的“加”是合并商品列表还是合并金额。这种非直觉语义会在 code review 和后续维护里反复消耗团队精力。同理如果一个运算符重载的实现需要“偷偷改掉对象内部状态”也基本可以判定为设计错误——运算符重载应当是无副作用的纯计算输入两个值返回一个新值完事。我还有一个习惯性判断标准如果一个操作你很难用一句话说清语义那就不该重载。a b如果不能用“把两者的值相加/合并并返回新值”这句人话解释清楚就别碰。2. 写重载前的必修课签名约束、成对规则与编译器映射2.1 五种签名规则违反一条就编译不过运算符重载的声明格式很固定所有重载方法都必须是public static而且必须含参数。不要问我为什么不能是实例方法——运算符是二元不对称运算编译器解析left right时需要考虑两个操作数的类型实例方法天然没法表达这种“左右开弓”的对称性。签名上有五条硬规矩方法名必须是operator 符号比如operator 、operator 注意符号和 operator 之间有空格。参数列表至少要有一个参数的类型是“声明该运算符的所在类型”。比如你在Complex里写operator 两个参数可以都是Complex也可以一个是Complex一个是double但绝不能两边都没有Complex。二元运算符要有两个参数一元运算符要有一个参数。不能使用ref、out、in修饰参数C# 7.2 后可以用in但没必要。返回类型大多数情况下可以随意但比较运算符 ! 以及true/false运算符必须返回bool。举个例子下面这种跨类型加法是合法的public readonly struct Length { private readonly double _meters; public Length(double meters) _meters meters; public static Length operator (Length left, Length right) new Length(left._meters right._meters); public static Length operator *(Length left, double scale) new Length(left._meters * scale); // return 类型不非得是所在类型 public static double operator /(Length left, Length right) left._meters / right._meters; }Length * double很直观Length / Length返回一个无量纲的double也很自然——比率本来就是没有单位的。这个“返回类型可以不同于参数类型”的灵活性在单位换算场景里非常实用。2.2 哪些能重载、哪些不能以及成对出现的硬性要求网上很多表格又把简单事情搞复杂了。我按自己的记忆方式整理给你可以直接重载的运算符类别运算符一元算术/逻辑、-、!、~、、--、true、false二元算术、-、*、/、%位运算、|、^、、比较运算符、!、、、、转换运算符implicit、explicit不能直接重载的成员访问符.、方法调用()、索引[]赋值号以及所有复合赋值符、-、*、/等条件逻辑运算符、||空合并符??类型信息相关typeof、sizeof、new、default、nameof其他?:、、is、as、await、-这里有两个容易误会的点。第一不能重载但如果你重载了a b会自动可用因为编译器会把它改写为a a b。这个“免费赠送”很有用但它也意味着你的类型必须支持“用加法结果整体替换原值”所以可变结构体配合运算符重载的坑会在这时候显现后面翻车现场那节细说。第二和||不能直接重载但当你同时重载了true、false和或|时编译器会在特定条件下允许你写a b。这个机制很适合做条件 DSL第 5 章我会给一个实际例子。还有一个比较隐蔽的硬性要求部分运算符必须成对出现。成对组合与!与与true与false你重载了却不重载!编译器直接报 CS0216 之类的错误要求同时定义匹配运算符。这个规矩不是刁难而是逻辑对称性如果 A 等于 B 有定义那 A 不等于 B 必须是你定义的反面编译器不允许你只做一半。同理小于和大于本来就是互斥关系。2.3 反编译视角运算符重载其实是一组静态方法我想强调一下前面提过的观点因为它能帮你理解很多“奇怪现象”。运算符重载在编译成 IL 之后就是一个普通静态方法名字是系统规定的映射。比如operator 对应op_Additionoperator 对应op_Equalityoperator true对应op_True。你用 dnSpy 或 ILSpy 反编译一个第三方库看到op_Addition这样的方法名就知道这个类型重载了加法运算符。这个事实带来的推论很重要运算符重载是编译期绑定不走虚方法分派。也就是说left right里left和right的编译期类型决定了调用哪个重载而不是运行期实际类型。如果你在一个基类里重载了运算符子类实例参与运算时编译器看的可能还是基类的重载版本。所以运算符重载和多态基本是水火不容的。既然是静态方法调用JIT 对简单实现通常可以做内联优化性能不会差到什么地步。你不需要为了“性能”刻意避开运算符重载但也不要在热路径里把重载方法写成一坨复杂的模板代码那就得不偿失了。因为它是个“方法”你可以用方法组的形式引用。比如Complex.op_Addition(a, b)这类直接调用虽然不推荐但在反射、表达式树编译等场景里你是可以“看到”它的。3. 两个能直接抄的完整案例复数类与上位机读数结构体3.1 复数覆盖加减乘除、比较、转换的完整写法复数是最经典的运算符重载教学案例因为它包含了几乎所有运算符类型四则运算、等于判断、隐式转换、比较虽然没有自然序但至少等于要有。下面这个版本我按生产环境的习惯写了readonly struct、实现IEquatableT、同步重写Equals和GetHashCode。public readonly struct Complex : IEquatableComplex { public double Real { get; } public double Imaginary { get; } public Complex(double real, double imaginary) { Real real; Imaginary imaginary; } public static Complex operator (Complex left, Complex right) new Complex(left.Real right.Real, left.Imaginary right.Imaginary); public static Complex operator -(Complex left, Complex right) new Complex(left.Real - right.Real, left.Imaginary - right.Imaginary); public static Complex operator *(Complex left, Complex right) new Complex( left.Real * right.Real - left.Imaginary * right.Imaginary, left.Real * right.Imaginary left.Imaginary * right.Real); public static Complex operator /(Complex left, Complex right) { double denominator right.Real * right.Real right.Imaginary * right.Imaginary; if (denominator 0) throw new DivideByZeroException(复数除法除数为零); return new Complex( (left.Real * right.Real left.Imaginary * right.Imaginary) / denominator, (left.Imaginary * right.Real - left.Real * right.Imaginary) / denominator); } public static bool operator (Complex left, Complex right) left.Equals(right); public static bool operator !(Complex left, Complex right) !left.Equals(right); public override bool Equals(object? obj) obj is Complex other Equals(other); public bool Equals(Complex other) Real.Equals(other.Real) Imaginary.Equals(other.Imaginary); public override int GetHashCode() HashCode.Combine(Real, Imaginary); public static implicit operator Complex(double value) new Complex(value, 0); public override string ToString() ${Real} {Imaginary}i; }几个容易被新手忽略的细节我都写在了这个例子里operator 内部直接调用Equals这是一个经验做法。如果你在里手工写“逐字段比较”容易和Equals的实现出现偏差导致同一个类型在不同比较路径下行为不一致。让和Equals共用一套逻辑是最保险的做法。IEquatableComplex加上Equals(Complex other)这个强类型重载是为了让ListComplex、Dictionary、LINQ 的Contains、Distinct在比较时走强类型路径避免装箱和反射。implicit operator Complex(double value)意味着double可以直接赋给ComplexComplex c 3.14;合法。但反过来说Complex不能隐式转double因为复数的实部虚部取出哪个语义不清所以就算要做也应该用explicit。3.2 上位机读数场景批量累加、均值与阈值判断觉得复数太“数学”那就看一个工程场景。我做上位机采集时经常要处理一批传感器读数先把每一帧的数据加起来算平均再判断有没有超过安全阈值。如果没有运算符重载代码会写成total.Value sample.Value; total.Count;一旦逻辑多了满屏都是.Value。我定义一个TorqueSample结构体把“累加值 次数”封装成一个整体。加法运算符负责合并两组读数除法和阈值比较也一并封装进去public readonly struct TorqueSample { public double Value { get; } public int Count { get; } public TorqueSample(double value, int count 1) { Value value; Count count; } public double Average Count 0 ? 0 : Value / Count; public static TorqueSample operator (TorqueSample left, TorqueSample right) new TorqueSample(left.Value right.Value, left.Count right.Count); public static double operator /(TorqueSample sample, int divisor) sample.Average / divisor; public static bool operator (TorqueSample sample, double threshold) sample.Average threshold; public static bool operator (TorqueSample sample, double threshold) sample.Average threshold; public static bool operator (TorqueSample sample, double threshold) sample.Average threshold; public static bool operator (TorqueSample sample, double threshold) sample.Average threshold; }调用方的代码就变得非常接近业务口语TorqueSample total new TorqueSample(0, 0); foreach (var frame in frames) { total frame; } double avg total.Average; if (total 5000) { Log.Warning(扭矩均值超限当前均值 {Avg}, avg); }拆开看total frame能工作靠的正是“重载后复合赋值自动可用”的规则。total 5000看起来是拿样本和数字比较实际走的是operator (TorqueSample, double)。代码读起来像业务描述这就是运算符重载的意义。3.3 案例背后的设计取舍这两个案例看着简单其实背后藏着几条设计取舍值得展开说为什么用readonly struct而不是class因为运算符重载返回“新对象”的语义和不可变类型天然契合。你写a b得到的应该是一个全新的值而不是把 a 或者 b 改掉。readonly强制了这种不可变性从设计层面避免写出“副作用型运算符”。为什么阈值判断不直接写sample.Average 5000因为平均值的计算逻辑被封装了。调用方不需要关心TorqueSample内部是用 Value 还是 Count 算平均值只需要表达意图“这个读数是否超限”。这是“封装”在运算符层面的体现。为什么比较运算符只和double做比较不做TorqueSample和TorqueSample的比较因为两个平均值的比较意义不大业务上更常见的是“读数值 vs 阈值”。重载时不贪多只重载你真正需要的这是我反复强调的原则。4. 翻车现场盘点与Equals分裂、隐式转换泛滥、结构体可变性4.1 重载了却忘记同步Equals和GetHashCode字典.Contains的诡异表现这个坑我见过太多次了。你高高兴兴地重载了operator 然后写ListMyType.Contains(item)结果发现它根本不走你的判断结果和自己预期的完全不一样。原因在于很多 API 在比较时用的是EqualityComparerT.Default而不是。ListT.Contains、HashSetT、DictionaryTKey,TValue、LINQ 的Distinct/Contains/Except默认走的是EqualityComparerT.Default。这个默认实现的选择顺序大致是如果类型实现了IEquatableT走IEquatableT.Equals否则走object.Equals。operator 反而不在默认比较器的主要路径里。所以只重载而不实现IEquatableT、不重写Equals你会得到一套“分裂”的行为写a b时走你重载的逻辑写list.Contains(a)时走默认的相等逻辑对 struct 可能是逐字段反射比较对 class 可能是引用比较。这俩结果不一致排查起来极其痛苦。我的做法是形成一个固定四件套每次定义值类型都照抄public static bool operator (MyType left, MyType right) left.Equals(right); public static bool operator !(MyType left, MyType right) !left.Equals(right); public override bool Equals(object? obj) obj is MyType other Equals(other); public override int GetHashCode() /* 用成员算哈希 */;如果类型实现IEquatableT再加一个public bool Equals(MyType other)。这样、Equals完全同源GetHashCode基于同样的成员计算字典、集合、LINQ 全部行为一致。4.2 隐式转换泛滥方法重载决议瞬间变得不可预测implicit运算符很诱人因为它能让代码“顺滑”。比如Complex c 3.14;写起来多舒服。但滥用隐式转换会让编译器在重载决议时抓狂。想象一下你定义了一个Temperature类型给它加了隐式转换到double然后你的代码里某处重载了SomeMethod(Temperature)和SomeMethod(double)。调用SomeMethod(temp)时编译器会优先选Temperature版本这还算好。但如果调用SomeMethod(0)编译器就要想0是转成Temperature调第一个重载还是直接作为double调第二个重载可能不报错但语义已经变得脆弱。更麻烦的是一旦某些框架或第三方库也有大量重载隐式转换会让所有“看起来差不多”的类型互相乱窜编译错误和运行时误调用的概率飙升。我的经验是隐式转换只保留给“没有信息丢失且语义绝对清晰”的转换比如int到long、派生类到基类。自定义类型之间一律用explicit转换让调用方在用(Fahrenheit)tempC这类强转时明确知道这里有一层换算。实在想要“方便”可以提供一个ToDouble()之类的命名方法比隐式转换可读性高得多。4.3 可变结构体、连续比较与NULL判断的连环坑可变结构体 运算符重载是另一个经典组合坑。先看这段代码public struct Counter { public int Value; public static Counter operator (Counter left, Counter right) new Counter { Value left.Value right.Value }; } Counter c new Counter { Value 1 }; c new Counter { Value 2 };表面上c.Value变成 3没问题。但结构体是值类型c other实际是“先拷贝一份 c调用加法再把结果赋回 c”。如果Counter内部还有引用类型成员或者被放在数组、字典里这种拷贝替换会带来一些意想不到的“赋值后没生效”的感觉。所以一旦决定用结构体承载运算符重载最好直接声明readonly struct从一开始就断绝“改内部状态”的念头。还有a b c这种写法。很多人会把连续比较写成a b c以为是在数学课上写的“a 等于 b 等于 c”。在 C# 里这叫链式比较实际结果是(a b) c先得到一个bool再用这个bool去和 c 比较。bool和 c 的类型不同时编译器可能直接报错也可能因为你给 c 定义了隐式转换而“神奇”地通过编译——后者才是最可怕的因为运行时大概率不是你想要的语义。建议在团队规范里明确连续比较要写成a b b c。最后是 NULL 判断。给引用类型重载时最常见的翻车是在实现里直接访问成员而忘记判空public static bool operator (Person left, Person right) left.Age right.Age; // 这里 left 或 right 为 null 时直接 NullReferenceException重载后所有地方都会尝试走你这个方法包括person null。我见过有人为了修这个坑在实现里写了一堆ReferenceEquals(left, null)的防守代码结果和Equals的逻辑又冲突了。更干净的做法是要么干脆不要在引用类型上重载只在值类型上重载要么在里用left?.Equals(right) true这种安全调用模式并且把 null 判断逻辑和Equals保持一致。5. 进阶玩法checked溢出控制、true/false短路重载与用户定义转换5.1 checked/unchecked运算符让溢出不再静默如果你的自定义数值类型内部靠整数运算实现默认情况下整数溢出是静默发生的。这在做加密、校验、仪器数据累加时可能是致命的——某个中间结果悄悄回绕成负数后面所有计算都错。C# 从较新的语言版本开始支持为用户自定义运算符声明 checked 版本写法是在运算符前加checked关键字public readonly struct WrappingCounter { private readonly int _value; public WrappingCounter(int value) _value value; public static WrappingCounter operator (WrappingCounter left, WrappingCounter right) new WrappingCounter(left._value right._value); public static WrappingCounter operator checked (WrappingCounter left, WrappingCounter right) new WrappingCounter(checked(left._value right._value)); }这样在checked上下文中运行的代码比如项目里设置了/checked或者局部写了checked块会用 checked 版本溢出时抛OverflowException普通上下文里则用不带 checked 的版本保持原有回绕行为。这个特性在实现带校验的协议帧、计数器、哈希值时很有价值。5.2 true/false重载用写出可读的条件拼接和||不能直接重载但当你需要构建一个“条件对象”并且希望调用方用组合语义时true/false加上的配合就能派上用场。比如我做 SQL 拼接 DSL不引入一整棵表达式树的前提下定义了一个SqlConditionpublic readonly struct SqlCondition { public string Sql { get; } public object[] Parameters { get; } public SqlCondition(string sql, object[] parameters) { Sql sql; Parameters parameters; } public static bool operator true(SqlCondition condition) !string.IsNullOrEmpty(condition.Sql); public static bool operator false(SqlCondition condition) string.IsNullOrEmpty(condition.Sql); public static SqlCondition operator (SqlCondition left, SqlCondition right) { if (string.IsNullOrEmpty(left.Sql)) return right; if (string.IsNullOrEmpty(right.Sql)) return left; return new SqlCondition($({left.Sql}) AND ({right.Sql}), left.Parameters.Concat(right.Parameters).ToArray()); } }当编译器看到condA condB时会尝试翻译成先调用false(condA)如果 condA 已经是一个“空条件”false 为真整个表达式的结果就是 condA不再计算否则调用(condA, condB)。这样写出来的调用代码就是SqlCondition final filterByUser filterByDate filterByStatus;每一段条件可以单独维护组合逻辑却像自然语言。这种场景下true/false重载不是“提升性能”而是让 DSL 的短路求值语义成立。5.3 转换运算符与泛型约束的配合最后聊一个和“泛型”玩家息息相关的话题。经常有人问我能不能写一个泛型方法T AddT(T a, T b)约束为“支持运算符”答案是不行C# 的泛型约束里没有“必须有加法运算符”这种约束。你没法在泛型方法里直接写a b。常见的替代方案有两个。一是定义接口并约束public interface IAddableT { T Add(T other); } public static T SumAllT(IEnumerableT items) where T : IAddableT { T result default!; foreach (var item in items) result result.Add(item); return result; }类内部可以用运算符重载实现这个接口外部既能享受运算符的语法糖又能在泛型约束中“看到”加法能力。二是用表达式树在运行时动态编译加法表达式。这个方法灵活但复杂度和代价都不低一般用在规则引擎、计算引擎这类确实需要动态解析的地方普通业务代码没必要。我的建议是如果有明确的有限类型集合优先用接口约束如果类型完全未知且必须做任意数学运算再考虑表达式树。运算符重载本身就绑定在具体类型上想让它“泛化”成通用约束本身就是反着用这个特性。我在实际项目里还有个习惯每重载一组运算符就在注释里写清楚“这个运算符的业务语义是什么”。比如TorqueSample的注释我会写“合并两个采样周期累加值与次数同时相加”。这种注释不是啰嗦而是为了阻止下一个人误用。毕竟运算符重载让代码读起来像数学算式那是牺牲了“显式方法名”换来的清晰如果语义没说清这笔交易就亏了。运算符重载真正该用的场景永远是那几个科学计算、单位换算、值对象、DSL。它让代码从“调用方法的啰嗦”变成“表述业务的算式”这是它的价值。而它最大的代价就是容易让不了解设计意图的人误用。所以重载前先问自己一句这个符号读者能秒懂吗能就上不能就乖乖用命名方法吧。
