這是因為如果重寫Equals方法而不重寫GetHashCode方法，在使用Dictionary類的時候，可能會有一個潛在的Bug。 復制代碼 static Dictionary<Person, string> personValues = new Dictionary<Person, string>(); protected void Page_Load(object sender, EventArgs e) { AddPerson(); Person mike = new Person("Mike"); Response.Write(personValues.ContainsKey(mike)); //False } void AddPerson() { Person mike = new Person("Mike"); personValues.Add(mike, "mike"); Response.Write(personValues.ContainsKey(mike)); //True } 本段代碼輸出結果：True False 復制代碼 這段代碼的意思是，執行AddPerson()的時候，將idCode=Mike的Person對象存進Dictionary中，然後在Page_Load方法內，也同樣new一個idCode=Mike的Person對象，使用ContainsKey方法搜索是否存在此對象Key，結果是不存在此對象。 你可以會問，上一個建議中，我們已經重寫了Person類的Equals方法了，只要idCode相等，我們就可以認為他們是相等的了，為什麼此處會找不到Mike呢？ 答：這是由於CLR已經優化了Dictionary這種查找，實際上是根據Key值的HashCode來查找Value值的。CLR首先調用Person類型的GetHashCode方法，發現這貨根本就沒有重寫，於是就向上找Object的GetHashCode方法，Object為所有的CLR類型都提供GetHashCode默認實現，每new一個對象，CLR都會為該對象生成一個固定整形值，在對象生命周期內不會改變，對象默認的GetHashCode實現就是該整型值的HashCode，所以，雖然Mike值相等，但是HashCode是不相等的。 若要修正此問題，就必須重寫GetHashCode方法 public override int GetHashCode() { return this.IDCode.GetHashCode(); } 進一步改進：GetHashCode方法存在一個問題，它返回的是一個整形類型，而整形類型的容量長度遠遠無法滿足字符串的長度，也就是說，值不相同的情況下，HashCode可能存在相同的情況，為了減少產生相同HashCode的情況，做改進版本： public override int GetHashCode() { return (System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName + "#" + this.IDCode).GetHashCode(); } 小結：這個建議至少讓我了解了HashCode，以前重寫ToString方法的時候，就經常看到GetHashCode這個東東。
