Image和Bitmap类都没有实现自定义相等/哈希码逻辑的原因是什么？
从MSDN文档来看，似乎GetHashCode（）和Equals（）都没有在Bitmap中被覆盖。 它们都没有在Image中被覆盖。 所以这两个类都使用Object的版本只比较引用。 我不太相信所以我决定启动Reflector来检查它。 看来MSDN在这方面是正确的。
那么，为什么MS人员不会实现“比较逻辑”，至少对于Bitmap类来说，有什么特别的原因吗？ 我发现它对于Image来说是可以接受的，因为它是一个抽象类，但对于Bitmap类来说并非如此。 我可以看到在很多情况下计算哈希码可能是一个昂贵的操作，但如果它使用某种缓存它就没问题。
想要比较2个位图时，我是否不得不依靠比较每个像素来运行图片？
谢谢
让我们翻一下这个问题; 是否有任何特殊原因可以实施这样的事情？
首先，计算哈希值非常非常昂贵，这使得它几乎对哈希表等无用。 试着在一大堆1920×1200位图上做这个想象; 对每个位图执行一次甚至一次会使程序变慢。 我希望10次中有9次，当有人必须比较两个位图时，他们想要参考相等，而不是逐像素值相等。
你在问题中提到的不是懒惰的评价，而是缓存。 缓存是一个非常重要的function，每个function都从负100点开始。
考虑到所有这些，我对此的回答是不会覆盖这些方法，因为相对于实现和维护此类function的成本而言，被覆盖的版本对许多人来说并不是特别有用。 如果你真的想要逐像素比较（或校验和，或类似的东西），那么你总是可以在10行左右自己实现它们。
图像和位图通常是可变的引用类型。 可变引用类型永远不应该重写Equals(Object) ，因为Equals(Object)不应该报告两个对象在被调用时是否碰巧具有相同的状态，而是两个对象是否总是永远相等。 即使两个可变对象碰巧在某个时刻具有相同的状态，但这绝不意味着它们总会这样做。
.net框架中的平等语义非常标准化; 如果对位图的引用以您期望的方式测试相等，那么它似乎违反了最不可忽视的原则。
当运行MS未实现的内置位图比较时，需要求助于比较每个像素。 当然，MS可能会进行原始内存比较（可能是在一个不安全的块中），但如果你愿意，你可以做同样的事情。 无论如何，比较两个位图总是很昂贵。 并且你不能依赖哈希，因为计算哈希值通常会比比较昂贵……并且你将被迫依靠原始像素比较来validation哈希匹配时的相等性，因为哈希只能certificate不等式。
我没有提供Equals和GetHashCode在Bitmap中无用的演示。 但是，我已经提供了一个演示，他们经常会给用户带来惊人的意外成本，并且在普通用例中不会是一个好的解决方案。 为这样的类型添加额外的function是昂贵的，我不相信它会带来很多好处。 它往往会花费很多。 这是您应该自己实现的，或使用第三方库。