2、一不小心掉進陷阱
不知道你有沒有查看 SDK 的習慣，其實 SDK 裡面蘊藏著很多對我們解決問題有啟發作用的信息的。現在讓我們看看 SDK 裡面能否找到什麼蛛絲馬跡。
由於 products 的真身是 List<T>，所以我們有必要看看 List<T> 是如何實現 IList.Remove 的：
This method determines equality using the default equality comparer EqualityComparer.Default for T, the type of values in the list.
原來，List<T> 在 IList.Remove 中使用 EqualityComparer.Default 來判斷兩個對象是否相等。那麼 EqualityComparer.Default 又是如何得知兩個對象是否相等呢？
The Default property checks whether type T implements the System.IEquatable generic interface and if so returns an EqualityComparer that uses that implementation. Otherwise it returns an EqualityComparer that uses the overrides of Object.Equals and Object.GetHashCode provided by T.
把上面這段話結合 Code #02 來看，我們可以發現 List<T> 中的 IList.Remove 判斷兩個 Product 對象是否相等的方法是從 Object 根類繼承下來的 Equals 和 GetHashCode 方法，即比較兩個對象的引用是否指向同一個對象。
由於 GetProduct 方法每次返回的都是一個新的對象（暫時讓我們忘記對象緩存這家伙），於是就導致了集合裡面出現“不死”對象。
3、不要被同一顆子彈打中兩次
“不要被同一顆子彈打中兩次”原意是指同一個錯誤不要兩次犯，這句話暗含著對兩個表示錯誤的對象進行邏輯上的判等，就像上面需要判斷兩個 Product 的對象在邏輯上是否相等那樣。
至此，我們也知道了令 Remove 重新生效的兩個可選辦法是：
讓 Product 類實現 IEquatable<T> 接口；
為 Product 類重寫 Equals 和 GetHashCode 方法。
在大多數情況下，我們希望比較的並不是對象的引用，而是對象的內容，與此同時，我們又不太可能為了這些小對象勞師動眾地實現對象緩存，於是，你就很有可能在類似的代碼中邂逅“不死”對象了。
