我不能代表语言设计师说话，但从我的推理来看，这似乎是有意为之，合理的设计决策。
看看这个基本的f#代码，你可以把它编译成一个工作库。这是f#的合法代码，只重载了等号运算符，而不是不等式运算符:
module Module1
type Foo() =
let mutable myInternalValue = 0
member this.Prop
with get () = myInternalValue
and set (value) = myInternalValue <- value
static member op_Equality (left : Foo, right : Foo) = left.Prop = right.Prop
//static member op_Inequality (left : Foo, right : Foo) = left.Prop <> right.Prop
这就是它看起来的样子。它只在==上创建一个相等比较器，并检查类的内部值是否相等。
虽然不能在c#中创建这样的类，但可以使用为。net编译的类。很明显，它将使用重载操作符for ==那么，运行时使用什么!=?
The C# EMCA standard has a whole bunch of rules (section 14.9) explaining how to determine which operator to use when evaluating equality. To put it overly-simplified and thus not perfectly accurate, if the types that are being compared are of the same type and there is an overloaded equality operator present, it will use that overload and not the standard reference equality operator inherited from Object. It is no surprise, then, that if only one of the operators is present, it will use the default reference equality operator, that all objects have, there is not an overload for it.1
知道了这种情况后，真正的问题是:为什么要这样设计，为什么编译器不自己解决这个问题?很多人都说这不是一个设计决策，但我喜欢这样认为，特别是考虑到所有对象都有一个默认的相等运算符。
那么，为什么编译器不自动创建!=操作符呢?我不能确定，除非微软的人证实这一点，但这是我可以从事实推理得出的结论。
防止意外行为
Perhaps I want to do a value comparison on == to test equality. However, when it came to != I didn't care at all if the values were equal unless the reference was equal, because for my program to consider them equal, I only care if the references match. After all, this is actually outlined as default behavior of the C# (if both operators were not overloaded, as would be in case of some .net libraries written in another language). If the compiler was adding in code automatically, I could no longer rely on the compiler to output code that should is compliant. The compiler should not write hidden code that changes the behavior of yours, especially when the code you've written is within standards of both C# and the CLI.
至于它迫使你重载它，而不是去默认的行为，我只能坚定地说，它是在标准(EMCA-334 17.9.2)2。该标准没有具体说明原因。我相信这是因为c#从c++中借鉴了很多行为。有关这方面的更多信息，请参见下文。
当你重写!=和==时，你不必返回bool。
这是另一个可能的原因。在c#中，这个函数:
public static int operator ==(MyClass a, MyClass b) { return 0; }
和这个一样有效
public static bool operator ==(MyClass a, MyClass b) { return true; }
如果返回的不是bool类型，编译器就不能自动推断出相反的类型。此外，在你的操作符确实返回bool值的情况下，创建只存在于特定情况下的生成代码没有意义，或者像我上面说的，隐藏CLR默认行为的代码。
c#大量借鉴了c++ 3
当c#被引入时，在MSDN杂志上有一篇文章是这样谈论c#的:
许多开发人员希望有一种像Visual Basic一样易于编写、阅读和维护的语言，但它仍然提供了c++的强大功能和灵活性。
是的，c#的设计目标是提供几乎与c++相同的功能，仅牺牲了一点点方便，如严格的类型安全和垃圾收集。c#是完全模仿c++的。
在c++中，相等操作符不必返回bool值，正如这个示例程序所示，对此您可能不会感到惊讶
现在，c++并不直接要求重载补充操作符。如果编译示例程序中的代码，您将看到它运行时没有错误。然而，如果你尝试添加一行:
cout << (a != b);
你会得到
编译器错误C2678 (MSVC):二进制'!=':没有找到左操作数为'Test'类型的操作符(或者没有可接受的转换)'。
因此，虽然c++本身不要求您成对重载，但它不允许您在自定义类上使用未重载的相等操作符。它在。net中是有效的，因为所有对象都有一个默认的对象;c++则不然。
1. 顺便说一句，如果您想重载其中一个操作符，c#标准仍然要求您重载这对操作符。这是标准的一部分，而不仅仅是编译器。然而，当您访问用另一种语言编写的.net库时，关于调用哪个操作符的确定规则也适用，而这种语言没有相同的要求。
2. EMCA-334 (pdf) (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf)
3.还有Java，但这不是重点
